[wsjt-devel] Release Candidate WSJT-X 2.6.0-rc5, OpenSSL address not availabe
Hi Joe and developer's members, OpenSSL address linked in users guide of 260-rc5 is now off, "404". They may be as follows respectively. From For Win32 OpenSSL Light Package: https://slproweb.com/download/Win32OpenSSL_Light-1_1_1L.msi For Win64 OpenSSL Light Package: https://slproweb.com/download/Win64OpenSSL_Light-1_1_1L.msi To For Win32OpenSSL_Light-1_1_1s.msi: https://slproweb.com/download/Win32OpenSSL_Light-1_1_1s.msi For Win64OpenSSL_Light-1_1_1s.msi: https://slproweb.com/download/Win64OpenSSL_Light-1_1_1s.msi Regards, 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 2.6.0 RC1 : 'a7' message in FT8
Hello, I found 'a7' message in FT8 with Normal decoding while disabling AP. Does it show regardless "Enable AP"? Besides, 1.6.0 manual says 'a7' is shown at message component of "Call_1 Call_2 ?" though it also appears in CQ message. Belows are the list of 'a7' from ALL.TXT file. 220617_231200 7.041 Rx FT8-24 1.3 1091 JQ3BBQ JA0EKS PM87 a7 220617_231815 7.041 Rx FT8-14 0.6 2500 JH5CHY JQ2GWH 73 a7 220617_232145 7.041 Rx FT8-10 0.6 2500 JN7BPV JQ2GWH R-21 a7 220617_232215 7.041 Rx FT8-21 1.2 1732 7M4HIC JA0PBK PM96 a7 220617_233730 7.041 Rx FT8-15 -0.8 1594 CQ JR1EMO PM95 a7 220617_235930 7.041 Rx FT8-24 -0.2 923 JH9ATW JE2DIR 73 a7 220618_000545 7.041 Rx FT8 -2 0.2 779 JE2DIR 7N4NGN +01 a7 220618_000845 7.041 Rx FT8-19 0.0 648 JQ7BOF JK1MWK PM95 a7 220618_001015 7.041 Rx FT8-22 0.0 1855 JE2DIR JE1BFK QM05a7 220618_001045 7.041 Rx FT8-20 0.0 1854 JE2DIR JE1BFK QM05a7 220618_001145 7.041 Rx FT8-22 0.0 1854 JE2DIR JE1BFK QM05a7 220618_001600 7.041 Rx FT8-23 0.4 977 JP3SML JJ1BCB PM95 a7 220618_002815 7.041 Rx FT8-14 0.0 2351 CQ JH1RNS PM95 a7 220618_002900 7.041 Rx FT8-24 0.5 978 JA2ITK JJ1BCB PM95 a7 220618_003315 7.041 Rx FT8-23 0.0 1224 JQ7BQT JA9ASN PM86 a7 220618_003330 7.041 Rx FT8 -8 0.5 450 CQ JO1LAC QM06a7 220618_003430 7.041 Rx FT8 -4 0.1 2204 JA2ITK JH1OBY QM05 a7 220618_003500 7.041 Rx FT8 -5 0.1 2204 JA2ITK JH1OBY QM05 a7 220618_003900 7.041 Rx FT8-24 0.0 1608 JJ3UBI JN1WGZ 73 a7 220618_003945 7.041 Rx FT8-16 0.1 2153 JN1FVW JH1FNU +09a7 220618_005700 7.041 Rx FT8-24 0.1 1206 JM4CNU JA6FOD R-03 a7 220618_011730 7.041 Rx FT8-16 -0.0 2479 JA3CAW JA9KTT RR73 a7 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Split operation in VHF and submode features enabled
Hi Bill, Thank you for prompt reply. I understand your explanation. I am using Q65A mode with 6mb usually, but I want the split operation to be normal. Is there any inconvenience with disabled "VHF and submode features", though Q65 quick start quide recommends it should be active? Current RC allows to set "Enable averaging" and "Auto Clear Avg after decode" even when VHF is disabled at Settings. 73 Yukio JG1APX On Sun, 22 Aug 2021 16:37:07 +0100 Bill Somerville via wsjt-devel wrote: > On 22/08/2021 15:35, Yukio JG1APX via wsjt-devel wrote: > > Hi development teams > > > > I apologize my report if it is already known issue and discussed before. > > > > OS : Windows 10 pro 21H1 > > Wsjtx : 2.5.0rc5 > > Rig : IC-9700, FT-991A, FTDX-3000, FTDX-101 > > > > Split operations (Rig and Fake It) are not working properly at JT4, JT9, > > JT65 and Q65 modes if "VHF and submode features" is enabled. > > In case of split by "Rig", the frequency of VFO-B (VFO-Sub) becomes the > > same as VFO-A (VFO-Main). PTT works with VFO-B or VFO-Sub as usual. > > In case of "Fake It", VFO-A (VFO-Main) keeps the same frequency as RX. > > Attached file shows the results. I quess it is not a Hamlib issue. > > > > Is this behavior working programmatically as planned? I find that online > > user guide has been written on 8.1. VHF Setup, "On the Radio tab select > > Split Operation (use either Rig or Fake It; you may need to experiment > > with both options to find one that works best with your radio)". Split > > operation seems to be recommended. However, the note about the behavior > > could not be found in the manual. > > Besides, I went back to review older versions, 2.2.0, 2.3.0. and 2.4.0. > > The results were the same. > > > > Best regards, > > > > Yukio > > JG1APX > > Hi Yukio-san, > > this is expected behaviour. The modes you mention all have wider variants > where forcing the lowest tone above 1500 Hz would cause the modulation to be > near or outside of upper bounds of a typical Tx filter. > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC4 Q65 behavior of averaging function
Hi Hasan, Thanks for your reply. I agree to your advice that it is better to turn "Autoclear Average After Decode" ON. I will do so and other one too. My Q65 setting has been with: Decode = Fast Enable Averaging = Off Autoclear Average after Decode = Off Single Decode = Unchecked In other QSO, I saw end-of-line code was indicated properly as q34. Something might be wrong in that case I reported previously. I need to learn the difference of "Enable averaging" between ON and OFF. Thanks for your advice. 73 Yukio JG1APX On Sun, 28 Mar 2021 05:02:30 -0500 Hasan N0AN wrote: > From what we can tell after several hours of testing: > > It is better to turn "Autoclear Average After Decode" ON > > Decode drop down menu > > If you don't, two things happen: > > 1) Auto Sequence is quite broken > 2) Info in Average Decodes pane is misleading if not outright wrong. > > So use settings: > > Decode = Fast (does not matter, as one depth seems to be selected no matter > setting) > Enable Averaging > Autoclear Average after Decode (ON) > Do Not Check Single Decode in Settings > General > > With these settings: > > Autoseq then seems to work and the Average Decode and skip frame counter > appear to work just as expected. > > The small window counter at the bottom of the main pane will increment each > time a decode is missed, When a decode happens, no matter if AP only or > even with Averaging, the counter is reset to zero. So it functions as a > frame skip counter. if you have 3 missed decodes , it will show 3 and if > you get an average decode on the next seq it will reset to 0 and your > decode will end in q34. > > That's how things appear to work so far. (If you AutoClear Average After > Decode) > > If you don't set it that way, you are on your own as the results are not > usable, at least with my limited analytical skills. > 73, N0AN > Hasan > > > On Sun, Mar 28, 2021 at 1:38 AM Yukio JG1APX > wrote: > > > Hello all, > > > > I have a question about the behavior of Q65 averaging function. > > My Q65 decoding shows two same messages per one signal and "qP*" at > > end-of-line code on one of two messages even if "Enable averaging" is > > unchecked. > > For instance, there are UTC 025000, 025100, 025200, 025430, and 025530. > > > > 1) Is it a proper operation to indicate the same message in double? > > > > In Release Notes, > > - If "Single decode" is unchecked, look for Q65 decodes from > >accumulated average even after obtaining a single-sequence > >decode at selected Rx Freq. > > > > My setting is "Single decode" unchecked. Does this behavior relate to > > the explanation of the Release Notes? > > > > 2) In "qP*" code, "*" seems to show averaging instead of the number of > > the averaging times. What is it? > > > > Thanks for in advance. > > > > 73 Yukio > > JG1APX > > > > ___ > > wsjt-devel mailing list > > wsjt-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RC4 Q65 behavior of averaging function
Hello all, I have a question about the behavior of Q65 averaging function. My Q65 decoding shows two same messages per one signal and "qP*" at end-of-line code on one of two messages even if "Enable averaging" is unchecked. For instance, there are UTC 025000, 025100, 025200, 025430, and 025530. 1) Is it a proper operation to indicate the same message in double? In Release Notes, - If "Single decode" is unchecked, look for Q65 decodes from accumulated average even after obtaining a single-sequence decode at selected Rx Freq. My setting is "Single decode" unchecked. Does this behavior relate to the explanation of the Release Notes? 2) In "qP*" code, "*" seems to show averaging instead of the number of the averaging times. What is it? Thanks for in advance. 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Auto Seq behavior of RRR on wsjtx v2.4.0 rc3
Hello, I knew in WSJT-X v2.4.0-rc3, which the behavior of message RRR in Auto Seq has been changed. As of v2.4.0-rc2, 73 message has been sent at the RRR sequence in any case. The rc3 quit sending a standard 73 message after received a standard 73 message from opposite station, but will keep sending the 73 message if a free message including "73" is received. Is it the desired behavior on the rc3? If you want to be consistent, I think it of should have no 73 message at the RRR sequence in any case. Best regards, 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FT4 VFO behavior on VHF and submode features on WSJT-X 2.4.0-rc3
Hello wsjtx development team, I reported the behavior of FT4 VFO split operation at "VHF and submode features" yesterday and found a possible cause in the source code of mainwindow.cpp later. In line 7100, there is an exception handing of FT8 and FST4 modes, but FT4 is missing. I am not sure other additional retouch is necessary. Today, I had the build of the wsjtx2.4.0rc3 added "FT4" into line 7100. Then, I got the desired behavior. FT4 should be there. 73 Yukio JG1APX Forwarded by Yukio JG1APX --- Original Message ------- From:Yukio JG1APX To: WSJT software development Date:Thu, 18 Mar 2021 12:02:44 +0900 Subject: [wsjt-devel] FT4 VFO behavior on VHF and submode features on WSJT-X 2.4.0-rc3 Hello wsjtx development team, I have noticed a behavior at FT4 mode on "VHF and submode features". If "Rig" split operation is set in configuration, VFO-B becomes the same as VFO-A. It is the same as that of JT4, JT9, JT65 and Q65 modes. In FT4, which is said to be a contest specification in HF bands, I think the operation should work as well as FT8 and FST4 modes. Since I set "VHF and submode features" always enabled and change band/mode between FT8/FT4 in HF bands and Q65 in 6m, there is no benefit of split operation in FT4. If it is already known issue, sorry please disregard my comment. It has been found on win10 pro and version on wsjt-x 2.3.0,.., and 2.4.0rc-3. It's a small matter, but if intentionally is made so. No comment further. Regards, Yukio, JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ----- Original Message Ends 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FT4 VFO behavior on VHF and submode features on WSJT-X 2.4.0-rc3
Hello wsjtx development team, I have noticed a behavior at FT4 mode on "VHF and submode features". If "Rig" split operation is set in configuration, VFO-B becomes the same as VFO-A. It is the same as that of JT4, JT9, JT65 and Q65 modes. In FT4, which is said to be a contest specification in HF bands, I think the operation should work as well as FT8 and FST4 modes. Since I set "VHF and submode features" always enabled and change band/mode between FT8/FT4 in HF bands and Q65 in 6m, there is no benefit of split operation in FT4. If it is already known issue, sorry please disregard my comment. It has been found on win10 pro and version on wsjt-x 2.3.0,.., and 2.4.0rc-3. It's a small matter, but if intentionally is made so. No comment further. Regards, Yukio, JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Windows JTSDK 3.1 x64 Patches: Preparation for imminent release of Qt 5.15.1
Steve, I will send my comment to your email address if any. Thanks. 73 Yukio JG1APX On Thu, 20 Aug 2020 06:18:35 + Stephen VK3SIR via wsjt-devel wrote: > Yukio, > > Fixed. It has been emailed to you personally and uploaded to JTSDK @ > GROUPS.IO. > > I have no idea how that has happened - NotePad++ has been the editor used. > > Can comments on this kit please either come directly to my email (vk3sir @ > hotmail.com) or be posted at JTSDK @ GROUPS.IO if you have access there? That > way we can contain the development process and guidance for future work in > one place :-). > > 73 > > Steve I > VK3VM / VK3SIR > > -Original Message- > From: Yukio JG1APX > Sent: Thursday, 20 August 2020 3:03 PM > To: WSJT software development > Subject: Re: [wsjt-devel] Windows JTSDK 3.1 x64 Patches: Preparation for > imminent release of Qt 5.15.1 > > Hi Steve, > > I have not yet upgraded to 5.15. It is interesting. > I noticed that "setqtver.cmd" of 0.4a is something wrong and the content is > for "build-hamlib.sh". > > 73 Yukio > JG1APX > > > On Thu, 20 Aug 2020 01:28:34 + > Stephen VK3SIR wrote: > > > Hi Folks, > > > > As many are aware "patches" that make the Windows JTSDK 3.1 x64 operate > > basically to the same processes and procedures that the well-established > > JTSDK 3.0 x86 operates to/under have been released to the JTSDK @ GROUPS.IO > > (i.e. https://groups.io/g/JTSDK/topics ) JTSDK Tech Group. > > > > I stated that updated patches to support Qt 5.15.1 would be released once > > this version was released. The release of Qt 5.15.1 is imminent. > > > > There are issues in that The Windows Qt 5.12, 5.13 and 5.14 streams are > > based on GCC 7.3.0 ? so script-work is easy. The Windows > Qt 5.15 stream > > supports GCC 8.1.0. > > > > I have an "alpha" version of patches available ? that will be imperfect and > > will need thorough and proper testing and refactoring. Note that these > > packaged scripts have been left as close as possible to Greg KI7MT's > > original scripts ... so please respect his IP. I will post a 0.4 alpha > > version of patches at JTSDK @ GROUPS.IO (i.e. > > https://groups.io/g/JTSDK/topics ) in the next few minutes. > > > > I regret not being able to add people to the JTSDK Developers' site but > > only a few of us have post access there. > > > > If you are unable to post back constructive comments and improvements to > > that site please post comments back to me with an authorisation as to > > whether comments can be reposted by me. > > > > I state that this is set up and used at the moment primarily as a learning > > base for others to understand how to package up resources to compile code > > that is cross system ? cross platform capable. > > > > 73 > > > > Steve I > > VK3VM / VK3SIR > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Windows JTSDK 3.1 x64 Patches: Preparation for imminent release of Qt 5.15.1
Hi Steve, I have not yet upgraded to 5.15. It is interesting. I noticed that "setqtver.cmd" of 0.4a is something wrong and the content is for "build-hamlib.sh". 73 Yukio JG1APX On Thu, 20 Aug 2020 01:28:34 + Stephen VK3SIR wrote: > Hi Folks, > > As many are aware “patches” that make the Windows JTSDK 3.1 x64 operate > basically to the same processes and procedures that the well-established > JTSDK 3.0 x86 operates to/under have been released to the JTSDK @ GROUPS.IO > (i.e. https://groups.io/g/JTSDK/topics ) JTSDK Tech Group. > > I stated that updated patches to support Qt 5.15.1 would be released once > this version was released. The release of Qt 5.15.1 is imminent. > > There are issues in that The Windows Qt 5.12, 5.13 and 5.14 streams are based > on GCC 7.3.0 ? so script-work is easy. The Windows > Qt 5.15 stream supports > GCC 8.1.0. > > I have an “alpha” version of patches available ? that will be imperfect and > will need thorough and proper testing and refactoring. Note that these > packaged scripts have been left as close as possible to Greg KI7MT’s original > scripts … so please respect his IP. I will post a 0.4 alpha version of > patches at JTSDK @ GROUPS.IO (i.e. https://groups.io/g/JTSDK/topics ) in the > next few minutes. > > I regret not being able to add people to the JTSDK Developers’ site but only > a few of us have post access there. > > If you are unable to post back constructive comments and improvements to that > site please post comments back to me with an authorisation as to whether > comments can be reposted by me. > > I state that this is set up and used at the moment primarily as a learning > base for others to understand how to package up resources to compile code > that is cross system ? cross platform capable. > > 73 > > Steve I > VK3VM / VK3SIR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X GA release, Spectrum display
Hi Bill, Thanks for your prompt reply. I understand WSJT-X to start with a command line option of '--language=en'. Unfortunately, user who read a 'Release Note.txt' is not so much in Japan, I guess. But, Ooba-san will disclose his translated one to Japanese later and many Japanese people will access his web page. If the issue is hard to solve, I believe 'Current', 'Cumulative', 'Linear Avg', and 'Reference' are possible to remain as is. ie. none translations. Then, they should be removed from translation ts file. I think of Ooba-san's one seem to have direct and meaningful translation. His transIation is a great. 73 Yukio JG1APX > Hi Yukio san, > > thank you for the issue report, that seems an unfortunate consequence of > providing a UI translation and I will investigate why that is happening. For > now you can start WSJT-X with a command line option of `--language=en` or `-l > en` to disable UI translations. > > I am unsure if we should try to translate the mode designations, they are > very fundamental to the operation of WSJT-X and I am also not sure that such > a translation would be possible given that most of the mode prefixes are > initials of the names of the designers of the modes. Does your language even > have direct and meaningful translations of initials of names written in a > Latin script? > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X GA release, Spectrum display
[Resending with the correction] Hello develop team, I am using the GA release with Japanese language. I found that there is no depict of spectrum in the display at the widegraph once the display method is changed from "Current" to another. To resume the function, the display method was changed back to "Current" but depicting spectrum was no more. I tried the language changed to Catalan and Spanish but the results were same as ours. An English is OK. I have a build with modified translation file such as to be no translation at the 4 kinds of the display methods. The result is a fine as an English. If there is a translation for the mode, it maybe bring a bug. I hope it will be corrected on the revised version. 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X GA release, Spectrum display
Hello develop team, I am using the GA release with Japanese language. I found that there is no depict of spectrum in the display at the widegraph once the display method is changed from "Current" to other. To resume the function, the mode was changed back to "Current" but the spectrum display was no more. I tried the language changed to Catalan and Spanish but the results were same as ours. An English is OK. I have a build with modified translation file such as to be no translation at the 4 kinds of the modes. It is a fine as an English. If there is a translation for the mode, it maybe bring a bug. 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x 220-rc3 wrong number of dbm:W in wspr message
Hi Bill I apologize for my mistake. I did download RC3 early time but have not installed it. Now, I confirmed this was fixed on the candidate. I'm sorry for taking the time. 73 Yukio JG1APX On Sat, 30 May 2020 14:36:14 +0100 Bill Somerville wrote: > > Hi Yukio san, > > this was fixed for WSJT-X v2.2.0 RC3, have to tested with that release > candidate? > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wsjt-x 220-rc3 wrong number of dbm:W in wspr message
Hello, I've found the wrong numbers at the list of dbm and power for wspr message from 220-rc1. For instance; 6 dBm 5 mW 16 dBm 50 mW 26 dBm 500mW 36 dBm 5W 46 dBm 50W 56 dBm 500W The message will be produced with the wrong dBm. I hope these to be corrected as same as previous version at the GA release. Thank you. 73 Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug report in mainwindow.cpp
Hi Joe Thank you. I am glad to hear that. 73 Yukio JG1APX On Sat, 23 May 2020 09:11:20 -0400 Joe Taylor wrote: > Hi Yukio-san, > > Thanks for alerting us to the omission of a mode-label color definition for > FT4, and the typo. They will be corrected in the next release! > > -- Joe, K1JT > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Bug report in mainwindow.cpp
Hello all
I have noticed minor things in mainwindow.cpp source code. If they are
already known, sorry about this.
v2.2.0 rc1 mainwindow.cpp :
1. FT4 background color of mode lable depends on previous mode.
The background color difinition is missing in setup_status_bar
(bool vhf) at line 2275 :
if ("ISCAT" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff9933}");
} else if ("JT9" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff6ec7}");
} else if ("JT4" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #cc99ff}");
} else if ("Echo" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #66}");
} else if ("JT9+JT65" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #66}");
} else if ("JT65" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #66ff66}");
} else if ("QRA64" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #99ff33}");
} else if ("MSK144" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff}");
} else if ("FT8" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #6699ff}");
} else if ("FreqCal" == m_mode) {
mode_label.setStyleSheet ("QLabel{background-color: #ff9933}"); }
2. m_send_RR73 from readSettings() at line 1203 :
m_send_RR73=m_settings->value("RR73",37).toBool();
'37' maybe typo. True or false for Bool() instead.
73
Yukio JG1APX
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Notification to use source code of wsjtx
Hello Development team Thanks for disclosing the source code of WSJT-X. I have a notification to you using the code. I have retouched it for my use by the reason below for a couple of years. I don't know if you know that we have been prohibited to communicate between JAs at some frequencies according to Radio Act in Japan. Maybe, an issue will be caused by new comer and/or JA user who does not understand our band plan. For instace, they call CQ station of JA at that frequency and then, JA opposite station responds automaticlly if autoseq and call 1st are enabled. There are not many happens but they are really annoying and disturbing to other JA station's Dxing. Patched source code ignores the messages from JA including "own callsign" at the specific frequencies. To avoid the communication between JAs. If there is the user who requests to use my version, I will share the build one and the source code based on the terms of the GNU General Public License. I will also pay attention to the manual if necessary. Thank you. 73, Yukio JG1APX ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
