Re: [wsjt-devel] WSJT-X ver 2.6.1 Spurious Hound TX after band change
This continues to be a problem at my station and it has the potential to damage my equipment as the spurious TX starts before my SteppIR has changed to the new band. Shouldn't WSJT-X clear out all generated messages on band change or, at a minimum, flag that F/H QSO attempt has ended. 73, Andy, k3wyc From: Andy Durbin Sent: Friday, February 16, 2024 8:19 AM To: wsjt-devel@lists.sourceforge.net Subject: WSJT-X ver 2.6.1 Spurious Hound TX after band change Several times I have completed an FT8 F/H QSO on one band then changed to another band with Hound mode still active. "Enable TX" is not active and no intended transmissions have yet been made on the newly selected band. However, WSJT-X starts a new transmission to the fox that had been worked on the previous band. e.g. 240216_14361524.911 Rx FT8-17 0.1 280 TO4A 4Z5KU KM71 240216_14363024.911 Rx FT8-16 0.1 665 HK4GSO 5X7O -07 240216_14363024.911 Rx FT8-17 0.1 785 I1YTO 5X7O -04 240216_14364524.912 Tx FT8 0 0.0 2262 5X7O K3WYC DM33 << QSO start 12 m 240216_14370024.911 Rx FT8-14 0.1 665 I1YTO 5X7O -04 240216_14370024.911 Rx FT8-14 0.1 726 K3WYC 5X7O -02 << In QSO 12 m 240216_14370024.911 Rx FT8-15 0.1 785 N9LEO 5X7O +00 240216_14371524.912 Tx FT8 0 0.0 726 5X7O K3WYC R-14 << In QSO 12 m 240216_14373024.911 Rx FT8-14 0.2 666 I1YTO 5X7O -06 240216_14373024.911 Rx FT8-14 0.2 725 K3WYC 5X7O RR73 << end QSO 12 m 240216_14373024.911 Rx FT8-16 0.2 785 N9LEO 5X7O +00 240216_14374524.911 Rx FT8 22 -0.3 239 TO4A OH1MM KP01 240216_14374524.911 Rx FT8 11 0.2 593 TO4A W4EU EM55 240216_14374524.911 Rx FT8 -7 0.5 916 TO4A EA3IGU JN11 240216_14374524.911 Rx FT8 -6 0.2 543 5X7O IW4APB JN45 240216_14374524.911 Rx FT8-13 0.1 408 TO4A UT2AA KO70 240216_14374524.911 Rx FT8 11 0.2 605 5X7O K4ZYU EM84 240216_14374524.911 Rx FT8 -8 0.2 893 TO4A DB7VX JN39 240216_14374524.911 Rx FT8-13 0.1 521 TO4A DF7XE JO31 240216_14374524.911 Rx FT8-22 0.1 838 TO4A R7FG LN04 240216_14374524.911 Rx FT8-15 0.2 280 TO4A 4Z5KU KM71 240216_14380024.911 Rx FT8-17 0.2 665 I1YTO 5X7O RR73 240216_14380024.911 Rx FT8-16 0.2 725 N9LEO 5X7O RR73 240216_14380024.911 Rx FT8-16 0.2 786 IW4APB 5X7O +07 240216_14381524.911 Rx FT8 13 0.1 666 5X7O KA5ZHG EL49 240216_14381524.911 Rx FT8 3 0.2 553 5X7O K4ZYU EM84 240216_14381524.911 Rx FT8 20 -0.3 238 TO4A OH1MM KP01 240216_14381524.911 Rx FT8-11 0.2 375 TO4A DD2MON JO41 240216_14381524.911 Rx FT8 -9 0.2 893 TO4A DB7VX JN39 240216_14381524.911 Rx FT8 -9 0.2 584 TO4A YO2LBV KN05 240216_14381524.911 Rx FT8-11 0.2 543 5X7O IW4APB R-12 240216_14381524.911 Rx FT8-15 0.2 408 TO4A UT2AA KO70 240216_14381524.911 Rx FT8-10 0.5 913 TO4A EA3IGU JN11 240216_14381524.911 Rx FT8-19 0.1 837 TO4A R7FG LN04 240216_14381524.911 Rx FT8-10 0.1 521 TO4A DF7XE JO31 240216_14381524.911 Rx FT8-20 0.2 479 TO4A 4Z5KU KM71 240216_14383024.911 Rx FT8-14 0.2 665 IW4APB 5X7O +07 240216_14383024.911 Rx FT8-14 0.2 725 HI3I 5X7O RR73 240216_14383024.911 Rx FT8-14 0.2 785 OH3LMN 5X7O -05 240216_14384524.911 Rx FT8 18 -0.3 238 TO4A OH1MM KP01 240216_14384524.911 Rx FT8 3 0.2 553 5X7O K4ZYU EM84 240216_14384524.911 Rx FT8-13 0.2 374 TO4A DD2MON JO41 240216_14384524.911 Rx FT8-10 0.2 893 TO4A DB7VX JN39 240216_14384524.911 Rx FT8 -6 0.2 585 TO4A YO2LBV KN05 240216_14384524.911 Rx FT8 -7 0.2 543 5X7O IW4APB R-12 240216_14384524.911 Rx FT8-18 0.2 408 TO4A UT2AA KO70 240216_14391528.080 Tx FT8 0 0.0 426 5X7O K3WYC R-14 <<< uncommanded TX on 10 m 240216_14393028.080 Rx FT8 5 0.4 393 WB8FVB 5X7O -17 240216_14400028.080 Rx FT8 -5 0.4 453 N4RJ 5X7O +08 240216_14400028.080 Rx FT8 -5 0.4 393 WB8FVB 5X7O RR73 Has anyone else seen this issue? Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X ver 2.6.1 Spurious Hound TX after band change
Several times I have completed an FT8 F/H QSO on one band then changed to another band with Hound mode still active. "Enable TX" is not active and no intended transmissions have yet been made on the newly selected band. However, WSJT-X starts a new transmission to the fox that had been worked on the previous band. e.g. 240216_14361524.911 Rx FT8-17 0.1 280 TO4A 4Z5KU KM71 240216_14363024.911 Rx FT8-16 0.1 665 HK4GSO 5X7O -07 240216_14363024.911 Rx FT8-17 0.1 785 I1YTO 5X7O -04 240216_14364524.912 Tx FT8 0 0.0 2262 5X7O K3WYC DM33 << QSO start 12 m 240216_14370024.911 Rx FT8-14 0.1 665 I1YTO 5X7O -04 240216_14370024.911 Rx FT8-14 0.1 726 K3WYC 5X7O -02 << In QSO 12 m 240216_14370024.911 Rx FT8-15 0.1 785 N9LEO 5X7O +00 240216_14371524.912 Tx FT8 0 0.0 726 5X7O K3WYC R-14 << In QSO 12 m 240216_14373024.911 Rx FT8-14 0.2 666 I1YTO 5X7O -06 240216_14373024.911 Rx FT8-14 0.2 725 K3WYC 5X7O RR73 << end QSO 12 m 240216_14373024.911 Rx FT8-16 0.2 785 N9LEO 5X7O +00 240216_14374524.911 Rx FT8 22 -0.3 239 TO4A OH1MM KP01 240216_14374524.911 Rx FT8 11 0.2 593 TO4A W4EU EM55 240216_14374524.911 Rx FT8 -7 0.5 916 TO4A EA3IGU JN11 240216_14374524.911 Rx FT8 -6 0.2 543 5X7O IW4APB JN45 240216_14374524.911 Rx FT8-13 0.1 408 TO4A UT2AA KO70 240216_14374524.911 Rx FT8 11 0.2 605 5X7O K4ZYU EM84 240216_14374524.911 Rx FT8 -8 0.2 893 TO4A DB7VX JN39 240216_14374524.911 Rx FT8-13 0.1 521 TO4A DF7XE JO31 240216_14374524.911 Rx FT8-22 0.1 838 TO4A R7FG LN04 240216_14374524.911 Rx FT8-15 0.2 280 TO4A 4Z5KU KM71 240216_14380024.911 Rx FT8-17 0.2 665 I1YTO 5X7O RR73 240216_14380024.911 Rx FT8-16 0.2 725 N9LEO 5X7O RR73 240216_14380024.911 Rx FT8-16 0.2 786 IW4APB 5X7O +07 240216_14381524.911 Rx FT8 13 0.1 666 5X7O KA5ZHG EL49 240216_14381524.911 Rx FT8 3 0.2 553 5X7O K4ZYU EM84 240216_14381524.911 Rx FT8 20 -0.3 238 TO4A OH1MM KP01 240216_14381524.911 Rx FT8-11 0.2 375 TO4A DD2MON JO41 240216_14381524.911 Rx FT8 -9 0.2 893 TO4A DB7VX JN39 240216_14381524.911 Rx FT8 -9 0.2 584 TO4A YO2LBV KN05 240216_14381524.911 Rx FT8-11 0.2 543 5X7O IW4APB R-12 240216_14381524.911 Rx FT8-15 0.2 408 TO4A UT2AA KO70 240216_14381524.911 Rx FT8-10 0.5 913 TO4A EA3IGU JN11 240216_14381524.911 Rx FT8-19 0.1 837 TO4A R7FG LN04 240216_14381524.911 Rx FT8-10 0.1 521 TO4A DF7XE JO31 240216_14381524.911 Rx FT8-20 0.2 479 TO4A 4Z5KU KM71 240216_14383024.911 Rx FT8-14 0.2 665 IW4APB 5X7O +07 240216_14383024.911 Rx FT8-14 0.2 725 HI3I 5X7O RR73 240216_14383024.911 Rx FT8-14 0.2 785 OH3LMN 5X7O -05 240216_14384524.911 Rx FT8 18 -0.3 238 TO4A OH1MM KP01 240216_14384524.911 Rx FT8 3 0.2 553 5X7O K4ZYU EM84 240216_14384524.911 Rx FT8-13 0.2 374 TO4A DD2MON JO41 240216_14384524.911 Rx FT8-10 0.2 893 TO4A DB7VX JN39 240216_14384524.911 Rx FT8 -6 0.2 585 TO4A YO2LBV KN05 240216_14384524.911 Rx FT8 -7 0.2 543 5X7O IW4APB R-12 240216_14384524.911 Rx FT8-18 0.2 408 TO4A UT2AA KO70 240216_14391528.080 Tx FT8 0 0.0 426 5X7O K3WYC R-14 <<< uncommanded TX on 10 m 240216_14393028.080 Rx FT8 5 0.4 393 WB8FVB 5X7O -17 240216_14400028.080 Rx FT8 -5 0.4 453 N4RJ 5X7O +08 240216_14400028.080 Rx FT8 -5 0.4 393 WB8FVB 5X7O RR73 Has anyone else seen this issue? Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46
"I have noticed the same thing at times while running as Hound in F/H where the report from the Fox will appear in the Band Activity column but not in the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel 231031 Improved PLUS" version." I think I have seen this once with ver 2.6.1. F/H QSO completed ok. I think it's rare but not new in the versions later than 2.6.1. It's a don't care for me as I'd prefer the RX frequency to only include decodes at the RX frequency as designated by the RX frequency cursor. Only commenting because I don't think it's a new bug. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Making F/H idiot proof
Hi Brian, The screen shot and the discussion are in the Clipperton groups.io messages. Clipperton is certainly using WSJT-X and operating as Fox. It appears the "user" saw a TX5S CQ and replied with TX3. TX5S responded with TX2. ref - https://groups.io/g/Clipperton-2024/message/388 You may need to sign up for the group to read messages. Private email if you like me to send a copy of the screen shot. I don't think this "list" will allow images. 73, Andy, k3wyc From: Brian Moran Sent: Wednesday, January 24, 2024 8:36 AM To: WSJT software development Cc: Andy Durbin Subject: Re: [wsjt-devel] Making F/H idiot proof Hi Andy; can you please help me understand the circumstances better? Under “normal” f/h operation, the hound calls with a grid. WSJT-X in fox mode can queue a caller with a grid. WSJT-X in fox mode doesn’t queue non-grid-supplying callers. If the “fox” replied to a signal report message as the first call, perhaps the fox wasn’t using f/h mode? Perhaps not using wsjt-x? The calling operator could have used the manual message selection buttons to change their message to the “fox” reflecting the circumstances, and they could have manually logged the station at the appropriate point in the sequence. It seems they might have partially done that, since if I understand what you are writing, they found and started with the TX3 message. If you could point me to more information and the screenshot, I’d like to follow up to understand this situation better. Thanks, -Brian N9ADG Sent via iPhone On Jan 24, 2024, at 7:16 AM, Andy Durbin via wsjt-devel wrote: As implemented in WSJT-X ver 2.6.1 the hound is able to select TX3 as their first transmission. One user has posted a screen shot showing that fox replied with a signal report but the QSO could not be completed. Since new WSJT-X ops seem reluctant to read the instructions would the developers please consider making TX3 unselectable until a signal report has been received. Thanks and 73, Andy, k3wyc ___ 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] Making F/H idiot proof
As implemented in WSJT-X ver 2.6.1 the hound is able to select TX3 as their first transmission. One user has posted a screen shot showing that fox replied with a signal report but the QSO could not be completed. Since new WSJT-X ops seem reluctant to read the instructions would the developers please consider making TX3 unselectable until a signal report has been received. Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.6.1 Failed to start OmniRig COM server
It turns out that this problem is very easy to reproduce. First some background on my configuration. The TS-590S has both a USB port and a traditional RS-232 COM port. The USB port connects to an internal USB hub which, in turn, connects to a USB UART for CAT and a PCM2903B USB Audio CODEC. In my station OmniRig is connected to the RS-232 COM port and does not use USB CAT. Starting with WSJT-X connected via OmniRig and connected to rig USB audio CODEC I pulled the rig USB cable I observed WSJ-X report loss of sound interface I went to Settings/Audio and saw Input TS-590 USB Audio CODEC not found I went to Settings/Radio and executed Test CAT - Failed with "failed to start OmniRig server" I restored the rig USB cable I went to Settings/Audio and restored the rig CODEC connection I went to Settings/Radio and Executed Test CAT - it failed. I terminated and re-started WSJT-X. It started with no errors. I see no reason why loss of USB Audio should cause WSJT-X to be unable to connect to OmniRig and think there may be an unintended dependency in the code. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.6.1 Failed to start OmniRig COM server
I have it working again. I had disconnected all cables from the laptop to access the battery. When I put it all back together I had swapped the cables for the TS-590S USB port and a 10 port USB hub. I only realized this error when WSJT-X did not see my TS-590S USB audio CODEC. When I put the USB cables back in the usual laptop ports the TS-590S USB audio CODEC was available to WSJT-X and, when it was selected for audio in and out, I could connect to OmniRig. I have a feeling there is a bug here but, at least for now, I'd rather chase DX than try to reproduce it. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X ver 2.6.1 Failed to start OmniRig COM server
I'm using WSJT-X ver 2.6.1 on a Win 8.1 laptop. I have been using OmniRig as my radio interface for many months and the only issue has been that first start after a new installation WSJT-X will fail to connect to OmniRig. It always connected ok for second and subsequent starts. Now I cannot connect to OmniRig with either ver 2.6.1 or with other older WSJ-X version I still have installed. I have other apps that use OmniRig and these connect and operate properly. OmniRig client runs fine in isolation. HDSDR and CW skimmer both connect to OmniRig either with client already running or without client running. It is only WSJT-X that is unable to connect to OmniRig. I have re-installed OmniRig with no change. I have verified that WSJT-X will connect to DXLab Commander. I have tried various saved WSJT-X configurations but none of these will connect to OmniRig. I know of no recent changes to my computer configuration that would have caused WSJT-X to no longer connect to OmniRig. Does anyone have any ideas what steps I can take to diagnose the problem or have any suggestions on how to fix it? Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] No 73 allowed after RR73?
After a review of ALL.TXT I no longer think this was related to prior use of F/H mode. I had set TX5 to a "CQ DX message" and that was auto sequenced after RR73 was received. I'll need to be careful to ensure TX5 is set correctly when in QSO. 73, Andy, k3wyc ____ From: Andy Durbin Sent: Saturday, October 21, 2023 12:14 PM To: wsjt-devel@lists.sourceforge.net Subject: No 73 allowed after RR73? WSJT-X ver 2.6.1, Win 8.1. I have observed several times that I could not complete a QSO by sending 73 after I had received an RR73. This is expected operation with F/H active but not when F/H is not active. I suspect that something is latched in software if F/H mode has been used but is then exited and WSJT-X is not re-started. Has anyone else seen this or have an explanation? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] No 73 allowed after RR73?
WSJT-X ver 2.6.1, Win 8.1. I have observed several times that I could not complete a QSO by sending 73 after I had received an RR73. This is expected operation with F/H active but not when F/H is not active. I suspect that something is latched in software if F/H mode has been used but is then exited and WSJT-X is not re-started. Has anyone else seen this or have an explanation? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 3Y0J strange F/H operation
I worked 3Y0J 17 m FT8 February 11 at 1603 UTC. At that time they were transmitting "even" and had a clock error of 0.4 seconds. F/H hound mode worked as expected and moved me from 2579 to 256. I was very surprised to hear the reports of a large clock error causing their TX on the wrong cycle. The times when I had decoded 3Y0J on "odd" I had assumed it was a pirate and not called. When I had clear decodes of 3Y0J on "even" there were usually several stations also calling on "even" and sometimes below 1000. Lots of evidence that were many attempting to make FT8 QSO without decoding the DX they were attempting to work. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wsjtx-2.6.1: TX is activated when frequency is changed in the hound mode
Also seen in 2.6.0. Good to hear a fix has been coded. I was delaying making a report until after Bouvet QRT. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 Hound frequency - k3wyc
I made a copy of the ini file for the condition that connects to Omni-Rig and a separate ini file copy for the configuration that does not connect to Omni-Rig. I compared the files using WinMerge. I see no obvious difference that would explain why one works with Omni-Rig and the other does not. I'll be happy to share the files with anyone interesting in investigating this. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 Hound frequency - k3wyc
" https://wsjtx.groups.io/g/main/message/40301 " Thanks for that link Martin. I attempted to change to a previously saved Fox/Hound configuration that worked fine in ver 2.3.0. It not only came up with a zero and red frequency box but it also failed to connect to Omni-Rig. When I switched back to my FT8 baseline version it connected to Omni-Rig ok. Selecting a configuration that was a copy of my FT8 baseline also connected to Omni-Rig. The failure to connect to Omni-Rig with a configuration that was saved by 2.6.0-rc5 with Hound active seems 100% repeatable. I reverted to ver 2.3.0 and found I could not connect Omni-Rig with my Fox/Hound configuration which had been working ok for months. Ver 2.3.0 still works ok with my FT8 baseline configuration. I saved a new copy of FT8 baseline, opened it, set Hound mode, imported a DXpedition frequency file, and then closed ver 2.3.0. I can now switch between FT8 baseline configuration and Hound configuration with both connecting to Omni-Rig. However, if I select the Hound config file that had worked for months before it was opened by 2.6.0 rc5, I cannot connect to Omni-Rig. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 Hound frequency - k3wyc
The -rc5 release notes say: - When in Hound mode and click the "H" button again, the frequency is now kept. This gives the user the following two options to return to normal FT8 mode: - Click the "H" button again. Then you will stay on the QRG. - Click the "FT8" button (or use the Settings menu). It brings you back to the default FT8 QRG. That seems to imply that the first press of "H" changes the QRG. I see no change in rig frequency and no change in the frequency list when "H" is first pressed. Neither pressing "H" again, not pressing FT8, has any influence on rig frequency or the frequency list. The only thing that seem to change any frequencies is program close and re-start. I had never used the "H" button in previous -rc versions so perhaps I don't understand how it is intended to work. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X v2.6.0-rcr5 Hound frequency - k3wyc
If WSJT-X 2.6.0-rc5 is closed with FT8 active and Hound not selected it restarts with standard frequencies available in the frequency selector. If Hound is selected the standard frequencies remain in the frequency selector. If WSJT-X is closed and re-started then it opens with Hound active and the Fox/Hound frequencies in the selector. If Hound is then deselected the Fox/Hound frequencies remain in the frequency selector. If WSJT-X is closed and re-started then the standard frequencies are restored to the frequency selector. If a restart is required to make the frequency selector consistent with the active mode then having a Hound button seems to offer no advantage over having a separate Fox/Hound configuration. The current implementation seems likely to cause much confusion. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 report - k3wyc
More detail on "Main window size/position is not remembered through shutdown re-start. (previously reported and seems to be in all versions since 2.3.0)" In addition to the previously reported issue that width and right edge position are not restored - With main window dragged to minimum width pressing Hound button causes nearly all elements of the lower part of the display to change width. When width is slightly greater than minimum only the message selector changes width. Also, the absolute minimum width that can be set is smaller with Hound selected than when Hound is not selected. I'd like the Hound minimum width to always be available. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 report - k3wyc
"Do you have split mode turned on? Does it behave if split mode is turned off? Mike W9MDB" Split was "Rig". No obvious difference with Split "None". Hang was not associated with crossing a 500 Hz boundary. Wide Graph hang can also be induced if the TX cursor is repeatedly moved within a 500 Hz segment with but it seems to be less obtrusive than for mouse movement, perhaps because of the change rate. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 report - k3wyc
WSJT-X ver 2.6.0-rc5 64 bit. Windows 8.1. TS-590S with Omni-Rig. I frequently slew the TX frequency cursor by clicking on the TX frequency box and using my mouse wheel. When I do that in 2.6.0-rc5 the wide graph pauses and may hang for a second. Sometimes the TX cursor has a delayed response to mouse wheel. I see no significant spike in CPU utilization when the mouse wheel is being moved. Same is observed when using the increment/decrement arrows of the TX frequency box. I see no interaction between moving the frequency cursor and the scrolling of wide graph in ver 2.3.0 or 2.5.4. I have not tested with earlier versions of 2.6.0. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X v2.6.0-rcr5 report - k3wyc
WSJT-X v2.6.0-rc5, Win 8.1 64 bit. TS-590S with OmniRig 1.19. When first opened after starting the band selector pull down list is abnormally wide. Normal width seen after selector closed and re-opened. (previously reported and seems to be in all versions since 2.3.0) Main window size/position is not remembered through shutdown re-start. (previously reported and seems to be in all versions since 2.3.0) The previously reported failure to connect to Omni-Rig on first start after installation was not seen with rc5. It's possible this was the result of a change in my local Omni-Rig initialization rather than a change in WSJ-X. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 report - k3wyc
More detail on "Main window size/position is not remembered through shutdown re-start. (previously reported and seems to be in all versions since 2.3.0)" I'm running a laptop PC with an additional monitor. I have the WSJT-X main window positioned in the lower right corner of the laptop screen. I set the window so the right edge is at the edge of the screen and the bottom of the window is just above the task bar. I then drag the left edge to set minimum width and drag the top to set desired height. I then close WSJT-X. When I re-open WSJT-X 2.6.0-rc5 the main window top, bottom, and left side are where I placed them. The window width is greater than I set and the right edge of the main window is off the side of laptop screen. I then have to drag the window back on screen and re-adjust the left edge back to minimum width. The problem was introduced after ver 2.3.0. If I close rc5 and open 2.3.0 the main window is positioned as I had set it in rc5. If I close 2.3.0 and open rc5 the right edge of the main widow is off screen. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X Wrong name for audio CODEC
WSJT-X versions 2.3.0, 2.5.4, and 2.6.0 rc4 do not display the correct audio device names if the names have been changed. Other apps, such as Soundcard Scope, show the current device name. E.g. I change my TS-590S audio CODEC name from "microphone" to "TS-590 RX". That name shows in the audio device list of Soundcard Scope but WSJT-X settings/audio does not show the revised name. The TX and RX audio path can still be correctly selected but the device names are not correct. Why doesn't WSJT-X use the current USB Audio CODEC device names? Thanks and 73, Andy k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Help with Omni-Rig
Uwe, Thanks for your reply. OmiRig is installed at C:\Program Files (x86)\Afreet\OmniRig. I can run it from there my clicking the exe or I can run it with the client, or I run it from HDSDR or CW Skimmer. I just can't run it from any version of WSJT-X. All versions of WSJT-X used to open Omni-RIg but now they don't. The only thing I know I did between it working and it not working is to update N1MM. Unfortunately I don't have a good restore point as they have all been deleted. I have tried uninstalling OmniRig and installing again from an archived copy of 1.19 but that changed nothing. When I uninstalled OmniRig I also deleted the C:\Program Files (x86)\Afreet\OmniRig directory. OmniRig still opens using a custom rig definition that is not included in the rig directory of C:\Program Files (x86)\Afreet\OmniRig. I don't know how it finds that rig definition. I see no hung processes in task manager. I'm running Windows Defender and I see no recent removed or quarantined items in history. If no other app could connect to Omni-Rig then I'd assume it was an Omni-Rig installation problem but other apps do connect to it. 73, Andy, k3wyc From: Uwe, DG2YCB Sent: Saturday, November 26, 2022 11:27 AM To: WSJT software development Cc: Andy Durbin Subject: Re: [wsjt-devel] Help with Omni-Rig Hi Andy, WSJT-X gets the path to OmniRig from Windows. No settings are required for this within WSJT-X. Usually, OmniRig installs into "C:\Program Files (x86)\Afreet\OmniRig" but the only thing that matters is which path is stored in the registry, and whether this path is correct. Please check if your firewall or your virus scanner block somehow the communication between WSJT-X and OmniRig. And see if there is a hanging process somewhere (wsjtx.exe, jt9.exe or omnirig.exe). I am using OmniRig myself. It works here very well with my Yaesu FT-991 and numerous WSJT-X versions. I am currently using 1.20, but 1.18 or 1.19 work as well. Yesterday or the day before, I noticed that some Windows update seemed to briefly interfere with the connection to OmniRig. But that has since resolved itself for me. 73 de DG2YCB, Uwe German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg2...@gmx.de<mailto:dg2...@gmx.de> Info: www.qrz.com/db/DG2YCB<http://www.qrz.com/db/DG2YCB> Am 26.11.2022 um 17:56 schrieb Andy Durbin via wsjt-devel: I have been running various versions of WSJ-X with Omni-Rig for many years. After having my station shut down for about a week I can no longer run WSJT-X with Omni-Rig. Error "Failed to start OmniRig COM server". If I run Omni-Rig client it connects to my TS-590S with no issue. If I close Omni-Rig client and open HDSDR or CW Skimmer both connect to Omni-Rig and establish 2 way communication with my TS-590S. It's clear that Omni-Rig and the client are working but it appears that WSJT-X either cannot find Omni-Rig client or is unable to start it. Where does WSJT-X expect to find Omni-Rig client and where is the path specified? I have found several discussions of this problem but have not found a solution. WSJT-X installation was not intentionally changed and I see the same problem with ver 2.3.0, ver 2.5.4, and 2.6.0 rc4. All these versions used to connect to Omni-Rig until this new problem started. I changed WSJT-X to start with admin privilege and have the same error. I also see the same with Omni-Rig 1.19 and 1.20. Omni-Rig client seems to have been unchanged since 2004. Any ideas on how to fix this? Thanks and 73, Andy k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto: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] Help with Omni-Rig
I have it working again but I don't understand why. I uninstalled two recent windows 8.1 updates - made no difference. I made a fresh installation of WSJT-X 2.3.0 in a new directory. it would not connect to Omni-Rig I started WSJT-X ver 1.9.1 from its BIN directory and it connected to Omni-Rig. I started WSJT-X ver 2.3.0 from its BIN directory and it connected to Omni-Rig I started the original version of WSJT_X ver 2.3.0 via a shortcut to the original 2.3.0 installation directory. It connected ok. I started WSJ-X ver 2.5.4 from a shortcut to its installation directory and it connect ok. I don't know what caused the problem and I don't know why it went away. The only thing I know was changed between WSJT-X not connecting to Omni-Rig and it connecting to Omni-Rig was that I ran WSJT-X ver 1.9.1. (I usually install each version in a separate directory and have lots of old versions available to run). Andy, k3wyc From: Andy Durbin Sent: Saturday, November 26, 2022 12:19 PM To: Uwe, DG2YCB ; WSJT software development Subject: Re: [wsjt-devel] Help with Omni-Rig Uwe, Thanks for your reply. OmiRig is installed at C:\Program Files (x86)\Afreet\OmniRig. I can run it from there my clicking the exe or I can run it with the client, or I run it from HDSDR or CW Skimmer. I just can't run it from any version of WSJT-X. All versions of WSJT-X used to open Omni-RIg but now they don't. The only thing I know I did between it working and it not working is to update N1MM. Unfortunately I don't have a good restore point as they have all been deleted. I have tried uninstalling OmniRig and installing again from an archived copy of 1.19 but that changed nothing. When I uninstalled OmniRig I also deleted the C:\Program Files (x86)\Afreet\OmniRig directory. OmniRig still opens using a custom rig definition that is not included in the rig directory of C:\Program Files (x86)\Afreet\OmniRig. I don't know how it finds that rig definition. I see no hung processes in task manager. I'm running Windows Defender and I see no recent removed or quarantined items in history. If no other app could connect to Omni-Rig then I'd assume it was an Omni-Rig installation problem but other apps do connect to it. 73, Andy, k3wyc From: Uwe, DG2YCB Sent: Saturday, November 26, 2022 11:27 AM To: WSJT software development Cc: Andy Durbin Subject: Re: [wsjt-devel] Help with Omni-Rig Hi Andy, WSJT-X gets the path to OmniRig from Windows. No settings are required for this within WSJT-X. Usually, OmniRig installs into "C:\Program Files (x86)\Afreet\OmniRig" but the only thing that matters is which path is stored in the registry, and whether this path is correct. Please check if your firewall or your virus scanner block somehow the communication between WSJT-X and OmniRig. And see if there is a hanging process somewhere (wsjtx.exe, jt9.exe or omnirig.exe). I am using OmniRig myself. It works here very well with my Yaesu FT-991 and numerous WSJT-X versions. I am currently using 1.20, but 1.18 or 1.19 work as well. Yesterday or the day before, I noticed that some Windows update seemed to briefly interfere with the connection to OmniRig. But that has since resolved itself for me. 73 de DG2YCB, Uwe German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg2...@gmx.de<mailto:dg2...@gmx.de> Info: www.qrz.com/db/DG2YCB<http://www.qrz.com/db/DG2YCB> Am 26.11.2022 um 17:56 schrieb Andy Durbin via wsjt-devel: I have been running various versions of WSJ-X with Omni-Rig for many years. After having my station shut down for about a week I can no longer run WSJT-X with Omni-Rig. Error "Failed to start OmniRig COM server". If I run Omni-Rig client it connects to my TS-590S with no issue. If I close Omni-Rig client and open HDSDR or CW Skimmer both connect to Omni-Rig and establish 2 way communication with my TS-590S. It's clear that Omni-Rig and the client are working but it appears that WSJT-X either cannot find Omni-Rig client or is unable to start it. Where does WSJT-X expect to find Omni-Rig client and where is the path specified? I have found several discussions of this problem but have not found a solution. WSJT-X installation was not intentionally changed and I see the same problem with ver 2.3.0, ver 2.5.4, and 2.6.0 rc4. All these versions used to connect to Omni-Rig until this new problem started. I changed WSJT-X to start with admin privilege and have the same error. I also see the same with Omni-Rig 1.19 and 1.20. Omni-Rig client seems to have been unchanged since 2004. Any ideas on how to fix this? Thanks and 73, Andy k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sou
[wsjt-devel] Help with Omni-Rig
I have been running various versions of WSJ-X with Omni-Rig for many years. After having my station shut down for about a week I can no longer run WSJT-X with Omni-Rig. Error "Failed to start OmniRig COM server". If I run Omni-Rig client it connects to my TS-590S with no issue. If I close Omni-Rig client and open HDSDR or CW Skimmer both connect to Omni-Rig and establish 2 way communication with my TS-590S. It's clear that Omni-Rig and the client are working but it appears that WSJT-X either cannot find Omni-Rig client or is unable to start it. Where does WSJT-X expect to find Omni-Rig client and where is the path specified? I have found several discussions of this problem but have not found a solution. WSJT-X installation was not intentionally changed and I see the same problem with ver 2.3.0, ver 2.5.4, and 2.6.0 rc4. All these versions used to connect to Omni-Rig until this new problem started. I changed WSJT-X to start with admin privilege and have the same error. I also see the same with Omni-Rig 1.19 and 1.20. Omni-Rig client seems to have been unchanged since 2004. Any ideas on how to fix this? Thanks and 73, Andy k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X v2.6.0-rc4 report - k3wyc
WSJT-X v2.6.0-rc4, Win 8.1 64 bit. First run after installation throws a rig control error. Radio is OmniRig Rig1 and Omni-Rig client is already running and connected to TS-590S when WSJT-X started. Error not seen if WSJT-X closed and re-started. First run after installation the band selector pull down list is abnormally wide. Normal width seen after close and re-start. Main window size/position is not remembered through shutdown re-start. All of these anomalies seem to have been introduced since v2.3.0 and none of then is seen after reverting to v2.3.0. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Regressions in WSJT-X ver 2.5.4
I seem to be having a bad day. I upgraded from 2.3.0 to 2.5.4. I have never downloaded or installed 2.5.0. So my revised report is: I updated from WSJT-X ver 2.3.0 to ver 2.5.4 both Win 64 bit and I noticed the following changes. I used the term regressions in the title because I think they are. The developers may not agree that this characterization is correct. 1. Main window size is no longer remembered through a shut down and restart. 2. First time used after start the frequency/band select window opens about double normal width 3. Deleted Sorry for the previous errors. Both 1 and 2 above are 100% repeatable on my system. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Regressions in WSJT-X ver 2.5.0
I updated from WSJT-X ver 2.3.0 to ver 2.5.0 both Win 64 bit and I noticed the following changes. I used the term regressions in the title because I think they are. The developers may not agree that this characterization is correct. 1. Main window size is no longer remembered through a shut down and restart. 2. First time used after start the frequency/band select window opens about double normal width 3. Interaction with JTAlert has changed for single clicked callsigns. In 2.3.0 any decoded call would move the RX frequency cursor and populate the Received frequency pane with the decode. In 2.5.0 only a subset of decoded calls is responsive. (See HamApps thread "No click response if CQ only). None of these changes prevents use of ver 2.5.0. but I have reverted to 2.3.0 because I prefer the way that it works. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Regressions in WSJT-X ver 2.5.0
re - Interaction with JTAlert has changed for single clicked callsigns. In 2.3.0 any decoded call would move the RX frequency cursor and populate the Received frequency pane with the decode. In 2.5.0 only a subset of decoded calls is responsive. (See HamApps thread "No click response if CQ only)." This statement was not correct. Please ignore. (Single click response depends on "CQ Only" as has not changed between 2.3.0 ad 2.5.0.) 73, Andy, k3wuc ________ From: Andy Durbin Sent: Thursday, January 27, 2022 8:14 AM To: wsjt-devel@lists.sourceforge.net Subject: Regressions in WSJT-X ver 2.5.0 I updated from WSJT-X ver 2.3.0 to ver 2.5.0 both Win 64 bit and I noticed the following changes. I used the term regressions in the title because I think they are. The developers may not agree that this characterization is correct. 1. Main window size is no longer remembered through a shut down and restart. 2. First time used after start the frequency/band select window opens about double normal width 3. Interaction with JTAlert has changed for single clicked callsigns. In 2.3.0 any decoded call would move the RX frequency cursor and populate the Received frequency pane with the decode. In 2.5.0 only a subset of decoded calls is responsive. (See HamApps thread "No click response if CQ only). None of these changes prevents use of ver 2.5.0. but I have reverted to 2.3.0 because I prefer the way that it works. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] dB report and actual bandwidth
Would someone please point me to an explanation of how the dB report of a received FT8 signal is derived. My recollection was that it was independent of the actual receiver bandwidth but simple experimentation shows that's not true. Simply narrowing the receiver bandwidth on a signal of interest results in a huge increase in the reported signal to noise ratio. This seems to imply that the noise being considered is the noise in the actual receiver passband and not the total noise in a 2.5 kHz bandwidth. Did I remember the implementation incorrectly or has the implementation been changed fairly recently? Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X option request - RX Frequency
"Andy - Is there a problem recognizing the RED background of the station you're in QSO as a method of tracking?" Yes, ALL the stations who are calling me are RED. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X option request - RX Frequency
Would the developers please consider providing the option to display in the "RX frequency" pane only callers on the RX frequency. If that option cannot be provided would you please change the name of the "RX frequency" pane to something that more accurately describes its function. Rationale - I use the RX frequency pane to track the progress of my current QSO. Having multiple callers who are attempting to interrupt my QSO also appear in the RX Frequency pane is sometimes a significant distraction from tracking and completing the current QSO. Yes, I know some people want these off frequency callers to be displayed in the RX Frequency pane. That is why I'm requesting an option. Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] JT65 message sequencing
WSJT-X ver 2.3.0 Win 64: I saw a JT65 signal on 40 m so I decided to change to that mode and work the QSO for nostalgia. My messages had to be manually selected for each transmission and there was no "Auto Seq" selection displayed. Is this by design? My recollection is that auto sequencing used to be possible with JT65. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Widegraph cursor frequency box
After installing WSJT-X ver 2.3.0 I have a cursor frequency readout box displayed every time my mouse cursor is over the Widegraph window even when no WSJT-X window has focus. How can I disable this? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Clipping
"40 dB down is pretty good for most consumer systems, but could produce spurs from it to someone who hears us very loud . If, for example, someone is 40 dB over S9, harmonics that are 40 dB over S9 would be S9! Sort of negates the advantage of some WSJT-X modes if the signal you're trying to copy is only S8." The reported harmonics were 40 dB down in the modulation audio not in the RF signal. For anyone using wsjt-x "split", true harmonics are outside the TX pass band. However, a closer look at the captured Spectrum Lab data shows these spurii are not actually harmonics at all. They appear to be mixing products resulting from the FT8 signal at 1500 Hz and the PCM2903B monotonic spurii at 1000, 2000, 3000, and 4000 Hz. Spurii seen at 500, 2500, 3500 and 4500 Hz follow the modulation tone sequence. These spurii may be only on the receiver side of the PCM2903B and may not be present on the TX side. In any event, my observation was that there there was no difference in TX Monitor spurii for the WSJT-X versions tested (except for the tone transition difference). Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Clipping
"Do you still see harmonics if you drop WSJT_X Pwr level to -0.4 or so?" I ran two tests with 2.4.0-rc1. One with Pwr at 0 dB and one with Pwr at about -1.4 dB. The 0 dB test was extra. All other versions were tested with approx -1.4 dB setting. (Why can't I read the setting by mousing over it? I have to change it to read it). There is no significant difference in the relative levels of fundamental and harmonics for the two different Pwr settings. In case it matters - Win 8.1 64 bit, TS-590S TX Moni feedback involves two passes through a PCM2903B which itself contributes some spurii. The PCM2903B spurii are fixed frequencies and are easily distinguished from the WSJT-X harmonics. With the exception of the change in characteristics at each tone change, I see no difference between the versions reported. I don't consider harmonics 40 dB below fundamental to a cause for concern. Audio clipping produces harmonics at much higher levels. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Clipping
I used Spectrum Lab to examine my TS-590S TX monitor audio for WSJT-X versions 1.9.1, 2.00, 2.2.1, and 2.3.0. All versions exhibit audio harmonics but each is about 40dB below the wanted modulation. There is a very noticeable difference in the primary modulation signal between WSJT-X versions. 1.9.1 and 2.0.0 show wide modulation with characteristics similar to key clicks at each tone change. Versions 2.2.1 and 2.3.0 show a softer change between tones with no "clicks". Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Clipping
"I used Spectrum Lab to examine my TS-590S TX monitor audio for WSJT-X versions 1.9.1, 2.00, 2.2.1, and 2.3.0. All versions exhibit audio harmonics but each is about 40dB below the wanted modulation." Same test, same results, with 2.4.0-rc1. All tests with FT8. Was the reported problem with a different mode? Andy k3wyc ____ From: Andy Durbin Sent: Sunday, February 14, 2021 1:23 PM To: wsjt-devel@lists.sourceforge.net Subject: Clipping I used Spectrum Lab to examine my TS-590S TX monitor audio for WSJT-X versions 1.9.1, 2.00, 2.2.1, and 2.3.0. All versions exhibit audio harmonics but each is about 40dB below the wanted modulation. There is a very noticeable difference in the primary modulation signal between WSJT-X versions. 1.9.1 and 2.0.0 show wide modulation with characteristics similar to key clicks at each tone change. Versions 2.2.1 and 2.3.0 show a softer change between tones with no "clicks". Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Green RX Mark
"Green RX Mark can not be set lower than 200Hzbut decodes a station at 161Hz" I hope the WSJT-X team never decides to inhibit decodes below 200 Hz. These stations can be worked with suitable techniques despite the fact that WSJT-X refuses to allow the TX and RX cursors to be placed below 200 Hz. (Most rigs have RIT, XIT, and a big tuning knob, and there is no requirement to respond on the other stations calling frequency) I decode from the bottom up to 5,000 Hz and have decoded and worked stations working well outside the "normal" frequency span. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Escape?
Joe, Thanks for the reply and for fixing the user guide link. It seems the reason a user guide search for "Escape" or "Esc" found no useful information is that the keyboard short cuts are in a screen capture image. I did look at a few links on Esc in Qt but heeded the advice to stay clear of Qt until having a basic understanding of C++. Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Escape?
WSJT-X ver 2.2.2 I learned from an on-line discussion that [Escape] could be used to clear messages. This morning I pressed Escape intending to clear the messages but the Wide Graph window was closed. I attempted to open the On Line User Guide from WSJT-X help menu. It returned "The requested URL /pulsar/K1JT/wsjtx-doc/wsjtx-main_en_US-2.2.2.html was not found on this server." I went to the WSJT-X site and opened the PDF version of the 2.2.2 User Guide and searched for "escape". There were no hits. Is Escape intended to close the Wide Graph window when it has focus and, if so, where is that documented? Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X defect report - Incorrect tab 2 grid message
Hi Joe, Thanks for your reply. "Would there be huge howls of protest if Tab 2 were permanently removed? If so, should we pay attention to them?" Perhaps the first question to ask is - How many users of WSJT-X use Tab 2 messages? If I'm the only one then there will be no howls of protest and I shall just have to get used to using Tab 1 messages. Yes, I came to WSJT-X from JT65-HF. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X defect report - Incorrect tab 2 grid message
WSJT-X 2.2.2 Win 64 bit. OS Windows 8.1:
Any valid call with a valid suffix will fail to generate a Tab 2 Grid message.
Clear DX Call and DX Grid fields
Select Message Tab 2
Press Grid message button - generated message is blank. As expected.
Enter "CALL" in DX Call field and press Grid - generated message is " {my
call} {my grid}". As expected.
Enter "CALL/7" in DX Call field and press grid - generated message is "
{my call} {report}". Not as expected.
Select Message Tab 1 - Observe " {my call} {my grid}" was correctly
generated.
73,
Andy, k3wyc
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] No response to decode click
"Is so, how should I work this station other than by manually typing the call into the "DX Call" field?" That seems to expose another problem. I typed BV2KI/9 into the DX call field and pressed Tab 2 "Grid". The message generated was " K3WYC +06". All the other Tab 2 buttons produce the expected messages. Tab 1 message 1 was " K3WYC DM33" but this message could not be generated from Tab 2. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] No response to decode click
WSJT-X v2.2.1, FT8 mode - If I click, or double-click, on this decode "145530 -15 0.3 1369 ~ CQ DX BV2KI/9" absolutely nothing happens. Is that expected behavior? Is so, how should I work this station other than by manually typing the call into the "DX Call" field? Other stations are calling BV2KI/9 and clicking their decodes e.g. "150245 6 0.1 1188 ~ WB6JHI CM97" moves the RX cursor and populates the RX Frequency "window". Thanks, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Rig verification
TS-590SG is included but not TS-590S. However there are rig control issues with TS-590S when using Commander and when using OmniRig. All have been previously reported and all have been discussed in detail with Bill. I abandoned using Commander with WSJT-X and have learned to live with the frequency setting error when using OmniRig. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 77, Issue 6
" * CAT commands to change frequency are rejected if the rig is in SEND mode, despite the fact that the rig can be tuned with the front panel VFO knob when transmitting." Same is true for the TS-590S (and probably the SG). Kenwood did not respond when asked why. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X Action on shutdown
"I'm the hamlib primary developer right now and not inclined to turn off the rig when closing the client.?" In my opinion WSJT-X should not make any change to the rig state when it shuts down. Several times I transitioned from working FT8 to attempting to work CW DX. If I shutdown WSJT-X while trying to work the DX the rig was taken out of SPLIT and I became the LID calling on the DX frequency. Totally unacceptable so I revised the OmniRig ini to prevent SPLIT control. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Wide Graph during TX
"My bad. I was thinking of the Wide Graph window. What is the purpose of Wide Graph progress? I don't think I have it enabled." My original post said "Wide Graph has always been frozen during TX for JT-65, JT-9, and JT65. It's been that way since the earliest versions of WSJT-X, but why?" In my reply I used the term "progress" to refer to the vertical motion, or lack of vertical motion, of the Wide Graph waterfall presentation. I regret that the term "progress" was confusing. I'll go back to using the term "frozen". Waterfall and spectrum of WSJT-X Wide Graph are frozen during TX because the designer(s) of the application chose that they should be frozen. The freezing of Wide Graph has nothing to do with the rig TX/RX state. Wide graph is frozen when WSJT-X transitions from RX to TX even if no rig is connected or powered on. The designer(s) of fldigi did not chose to disable the waterfall display during TX and it can serve as a useful TX monitor. I sometimes run fldigi with WSJT-X so I have a visual TX monitor. So back to my original question - Why does WSJT-X freeze Wide Graph during TX? 73, Andy, k3wyc From: Andy Durbin Sent: Sunday, June 7, 2020 9:51 AM To: wsjt-devel@lists.sourceforge.net Subject: Wide Graph during TX "The Wide Graph pauses because nothing is received for processing." No, you are mistaken. Wide Graph progress has nothing to do with signal reception. Secondly, my TS-590S provides feedback of the audio modulation. It is not based on RF. Some rigs, e.g some Flex, do provide TX monitoring at the RF level. However, it doesn't matter how the rig implements TX monitoring. The fact remains that many rigs do provide the ability to monitor the TX signal while transmitting and this signal can usually be provided on the same audio channel that provides WSJT-X the audio signal while receiving. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Wide Graph during TX
"The Wide Graph pauses because nothing is received for processing." No, you are mistaken. Wide Graph progress has nothing to do with signal reception. Secondly, my TS-590S provides feedback of the audio modulation. It is not based on RF. Some rigs, e.g some Flex, do provide TX monitoring at the RF level. However, it doesn't matter how the rig implements TX monitoring. The fact remains that many rigs do provide the ability to monitor the TX signal while transmitting and this signal can usually be provided on the same audio channel that provides WSJT-X the audio signal while receiving. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Wide Graph during TX
Wide Graph has always been frozen during TX for JT-65, JT-9, and JT65. It's been that way since the earliest versions of WSJT-X, but why? If Wide Graph continued to run during TX it would/could allow monitoring of TX audio for rigs that have that capability. Perhaps if people could see the shit they are sometimes transmitting they would do something to fix their signals. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RC3 with OmniRig
I changed from 2.2.1 Win 64 bit to 2.2.0-rc3 Win 64 bit. RC3 would not connect to OmniRig using the TS-590 file I had been using with ver 2.2.1. It also would not connect with the default OmniRig TS-590 file. However, when I closed RC3 and re-started with the default OmniRig TS-590 file, it connected ok. I was than able to change OmniRig back to the revised TS-590 rig file. Shut down and re-start of RC3 gave a normal connection to OmniRig. It would appear there is an OmniRig connection problem the first time RC3 is run after installation. The problem was not reproduced by stopping RC3, starting 2.2.1, stopping 2.2.1, starting RC3. While investigating the OmniRig connection problem I intentionally set RC3 to use OmniRig Rig 2 which is not defined. This gave an RC3 error - "wsjt-x.exe has stopped working". This appears to be repeatable as follows: Configure RC3 to use a valid OmniRig Rig 1 configuration Verify normal rig connection Select an undefined OmniRig Rig 2 - observe "Rig control error" followed immediately by "wsjt-x has stopped working" Select "close program" Restart RC3 - program does not shut down and Rig 1 can be selected Re-select an undefined OmniRig Rig 2 - observe "Rig control error" followed immediately by "wsjt-x has stopped working" The previously reported problem that my TS-590S is set to the wrong frequency when WSJT starts is still present in RC3. (frequency resolution test leaves TS-590 on wrong frequency). 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FT8 with click anomaly
I observed an FT8 signal that was "wide" in a similar way to a CW signal with key clicks. I listened to the signal and could hear what appears to be a regularly repeating series of clicks. The signal, which was from a local station, decoded normally. The linked WAV file was captured by, and edited in, Audacity. It does not replay in WSJT-X. https://tinyurl.com/y8ehtrkd I have never seen or heard an FT8 signal like this one. Does anyone know what could cause this anomaly? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg
"Both stations should log the QSO when RR73 is sent. At that point in the message sequence both QSO partners have exchanged call signs, reports and acknowledgements (R -04 and RR73). No further messages need to be exchanged." The flaw in this argument is that transmission of RR73 does not ensure reception of RR73. "Exchanged" requires both transmission and reception, 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Sometimes the "Decode" button hangs
I have seen decode hangs multiple times with v2.1.1 and I have reported that previously. In all cases the time keeps updating, and widegraph stays active. The only way I have found to recover is to restart WSJT-X. I attempted to find an association with wave files spanning the decode hang time. No wave files reproduced the problem reliably although once out of multiple attempts a wave replay did cause decode hang. I do not believe the decode hang has anything to do with the audio that was being received. It can happen during the night on a band that has no activity. I suspect it happens because the CPU is busy or a file cannot be accessed. It always, or almost always, happens when I'm away from the computer. I thought for a while that it was associated with an automatic file backup that runs late at night but I think it has also happened when the backup is not active. I've been saving screen shots to see if there is any clue in the displayed information but nothing found yet. In case it matters - Win 8.1 64 bit. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Green goalie not moving to the RX freq
"Why should it? Unless you're on Call 1st, you need to have the choice of who to answer (if any of them) if there's more than one. That happens quite often. It will move when you choose who to answer by double clicking him." Perhaps you did not read the post that I linked. It said - "WSJT-X ver 2.1.0 64 bit has an anomaly with RX frequency cursor positioning that I had not noticed in ver 2.0.1. I call CQ with "Hold TX freq", "Call 1st", and "Auto Seq" enabled. WSJT-X auto replies to a caller who is not at my TX frequency. Sometimes my RX cursor moves immediately to the caller's frequency, sometimes it moves later during the QSO, sometimes it never moves at all. Shouldn't the RX frequency cursor move to the caller's frequency as soon as WSJT-X has decided this is the "first caller" and starts to auto-sequence the QSO?" Please be sure to note - "I call CQ with "Hold TX freq", "Call 1st", and "Auto Seq" enabled. " 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Green goalie not moving to the RX freq
I could not find my report in the archive but I did find this explanation - https://sourceforge.net/p/wsjt/mailman/message/36491899/ I think the design needs to be changed because the "wide graph" signal is very informative about the QSO partners signal and that signal can't be found if the RX cursor is not on it. 73, Andy, k3wyc ____ From: Andy Durbin Sent: Saturday, April 25, 2020 10:43 AM To: wsjt-devel@lists.sourceforge.net Subject: Green goalie not moving to the RX freq "When I CQ and someone calls me the Green goalie does not auto move to his freq " I think I reported this a long time ago. The anomaly has certainly been there for a long time. It does not seem to be consistent though and perhaps that's why it has not been fixed. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Green goalie not moving to the RX freq
I found my report - https://sourceforge.net/p/wsjt/mailman/message/36745436/ The random behavior that I reported does not seem to be consistent with Joe's explanation. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Green goalie not moving to the RX freq
"When I CQ and someone calls me the Green goalie does not auto move to his freq " I think I reported this a long time ago. The anomaly has certainly been there for a long time. It does not seem to be consistent though and perhaps that's why it has not been fixed. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FT4 and FT8 Contesting
The debate as to when a QSO is complete will probably go on forever. The simple fact is that there are two parties involved in the QSO and they may disagree on whether the QSO was completed. If you send an RR73 you can log the QSO but if I didn't receive it then I'm not going to. If I don't need to receive your RR73 for the QSO to be complete then what's the point of sending it? The only way you know I received your RR73 is if you see my reply to it. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X - FT8 stuck in decode
This morning I found wide graph and input level frozen but Decode not lit. That was caused by "Error in Sound Input" and was fixed by cycling the Soundcard Input to a different source then back to TS-590 audio CODEC. The WSJT-X error window was not visible until the sound card input was cycled and then there were two instances of the message. The first instance was hidden under the WSJT-X main screen so it is possible there was an error message associated with the Decode lock but it was not visible. (Screen captures saved) Next time I'm locked in Decode I'll try to reveal any hidden error messages before re-starting WSJT-X. Why don't WSJT-X error messages always appear on top? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X - FT8 stuck in decode
"Is the waterfall still progressing when this happens? Is the Rx level thermometer type indicator still active when this happens?" Waterfall is still active and is showing signals. I believe the RX level is still active and don't see how it could not be if the waterfall is displaying signals. I'll check this next time it happens. I have turned on "Save All" and will see if I capture anything useful. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X - FT8 stuck in decode
I'm running WSJT-X v 2.1.1 64 bit on a Win 8 laptop. I often leave WSJT-X running overnight monitoring FT8 on 1.84 MHz. Most mornings the Decode light is on continuously and no decodes are being made. The only way I have found to recover from this is to re-start WSJT-X. I have been using WSJT-X since before version 1.0 was released and have often left it running for days at a time. The decode lock up is a fairly new issue. What is the cause and how can it be prevented? Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Callsign lockout
"That's ridiculous. A "block" wouldn't keep a station from transmitting, just from being displayed. Can't you just ignore it?" Not easy to ignore when all callers are displayed in Rx frequency window. A large part of this problem would be fixed by making the RX frequency window display only calls on the RX Frequency. If more complexity is allowed I would propose that: When not in QSO any and all callers are displayed in RX freq Once a QSO is started then only the station I'm in QSO with is displayed in RX freq window (this allows for a change in QSO partner's TX freq. When QSO ends go back to displaying all callers. All callers would still be displayed in Band Activity window so those that enjoy multi-tasking can be aware of who is calling. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Ver 2.1.1 with OmniRIg
I updated from 2.1.0 64 bit to 2.1.1 bit on my Win 8.1 laptop. I am configured to use OmniRig for rig control. The first time 2.1.1 was run it opened the OmniRIg setting window (OmniRig client was running before WSJT-X was started). When I closed that window Windows reported that WSJT-X had stopped running. When I restarted WSJT-X operation seems to be normal. Perhaps this is related to rig control issues that others are reporting. The issue that rig is set to wrong frequency on program start still remains. Set rig 14.075 for VFO A and B. Close WSJT-X - rig remains on 14.075 Start WSJT-X - VFO A is 14.074055, VFO B is 14.074000 Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Settings anomaly v2.1.0
Bill, Thanks for the reply. It's quite possible that I fat fingered something. I did find that closing the frequencies tab with the Settings window "X" does result in settings window being blank next time it is opened. I don't think I would have done that but of course it's possible. I could not induce a blank settings window by any other method. Anyway, I now have a configuration with VK9CZ frequencies and hope to work them for an ATNO. 73, Andy, k3wyc On 14/11/2019 14:37, Andy Durbin wrote: I cloned my baseline FT8 configuration file and renamed that copy to VK9CZ. I then added the published VK9CZ FT8 operating frequencies. When I closed settings I found that none of the added operating frequencies was shown in the main window frequency list. I then opened file/settings and was presented with a blank settings window. I reverted to my FT8 baseline configuration and opened file/settings. The normal Settings window was displayed. I switched to my VK9CZ configuration and opened file/settings. Now the normal settings window was displayed but the added frequencies were still missing. I "inserted" one new frequency and this was added ok. I then inserted the rest of the VK9CZ frequencies and no anomalies were seen. Has anyone else seen similar issues when inserting new frequencies? I doubt the problem is easy to reproduce. Andy, k3wyc Hi Andy, most likely that you forgot to exit the Settings dialog by clicking the "Ok" button. Settings changes are discarded unless you exit the Settings dialog by clicking "Ok". The blank Settings dialog window is a known issue, you can fix it by resizing the Settings dialog window. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Settings anomaly v2.1.0
I cloned my baseline FT8 configuration file and renamed that copy to VK9CZ. I then added the published VK9CZ FT8 operating frequencies. When I closed settings I found that none of the added operating frequencies was shown in the main window frequency list. I then opened file/settings and was presented with a blank settings window. I reverted to my FT8 baseline configuration and opened file/settings. The normal Settings window was displayed. I switched to my VK9CZ configuration and opened file/settings. Now the normal settings window was displayed but the added frequencies were still missing. I "inserted" one new frequency and this was added ok. I then inserted the rest of the VK9CZ frequencies and no anomalies were seen. Has anyone else seen similar issues when inserting new frequencies? I doubt the problem is easy to reproduce. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Need Paradigm Shift on Frequency List Entry
"As I said above, a CAT reset will cause a shift to a working frequency," Maybe the question should be - "Why does selection of F/H mode cause a CAT reset?" The transition from normal mode to F/H mode is more difficult than it should be. On some bands monitoring the standard FT8 frequency with 4k RX bandwidth allows F/H operations to be seen before they are spotted. It would be nice if the dial could be moved up 4k then F/H mode selected with a single mouse click instead of the multiple operations required to select a different configuration and then re-tune the fox. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] F/H free msg
In ver 2.1.0 F/H mode it is possible to compose and select a Tab 2 free message
but that message is not actually sent. Instead a {fox_call} {my_call}
{my_grid} message is sent. Either the message should be sent as selected or
the free message should not be selectable.
There are times when it may be useful to send a Free msg while in F/H mode as
that message could be addressed to someone other than the fox.
73,
Andy, k3wyc
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] TS-590 / N1MM / WSJT-X
After another visit to the N1MM group I found that, although my configuration works, it it not the best configuration to use. If N1MM is told the TS-590 USB Audio CODEC is an internal radio CODEC then the more intuitive keying option does produce the TX1; command. To set up N1MM for WSJT-X with a TS-590 ensure that "Internal Radio CODEC" is selected. This selection appears in either Configurer / Audio or in Audio Setup & Monitor / Payback depending on whether Config "Use Logger+ Audio" is enabled or not. When "Internal radio CODEC" is selected then Com / Details can be selected to "PTT via Radio Command Digital Mode" and will produce TX1; keying command. I knew there was a good reason I had been using DATA VOX keying for so long. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Grid proposal
Some people like to exchange grids on HF bands and some people don't need them. Those that want a grid may be frustrated by callers who don't provide one. Those that don't want a grid may be frustrated by those who extend the QSO by providing one. The solution seems simple to me - If you want callers to reply to your CQ with a grid then include your grid in your CQ. If you don't want the first reply to be a grid then don't include a grid in your CQ. If this is adopted as standard practice then WSJT-X could automatically select the appropriate reply to any CQ that is clicked. A Settings/Behavior option could be used to define if a CQ message is generated with, or without, a grid. Comments? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] TS-590 / N1MM / WSJT-X
"Unless N1MM Logger+ has a way of defining the command to use you may be out of luck unless VOX is usable." Bill, I received the answer via the N1MM group. The TX0; / TX1; selection is in Configurer / Radio / Details. When "TS-590" is selected as Radio then "Details" includes the option ""Digital Modes Acc Jack Radio Command PTT”. This must be selected to use TX1; for CAT keying. The option is not shown if radio is selected to "Kenwood"! The specific Kenwood radio model must be selected. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] TS-590 / N1MM / WSJT-X
I'm a long time user of WSJT-X with my TS-590S. I'm also familiar with setting up WSJT-X to use Commander, or OmniRig, or for a direct connection to the TS-590. I have attempted to set up WSJT-X with N1MM but have a problem with rig keying mode. When I press "Tune" - the rig is keyed, Windows shows audio output, but there is no power output. This is almost certainly an indication that N1MM / WSJT-X is sending TX0 instead of TX1. When integrated with N1MM the instructions say WSJT-X should be configured for rig - DX Lab Commander. Both DXLab Commander and WSJT-X have the option to control which keying command is used ( Commander = data transmission from USB interface or ANI interface / WSJT-X = transmit audio source). Where is the equivalent keying command selection when WSJT-X is pretending to use Commander but Commander is not actually in use? If anyone knows would you please point me to the menu setting, preferably with a screen shot. Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Occasional zero power indication when transmitting
"Unfortunately, I can not connect the no-audio tx fault to any particular operation" I have seen this problem several times but I have not found a way to reproduce it reliably. My impression is that it happens when a TX is manually initiated within the first second of the transmit period. I have never seen it when the QSO is auto sequenced. Perhaps the vulnerability is manually initiating a TX in the period between normal CAT TX enable time and normal modulation start time. I don't remember seeing the problem with ver 2.1.0 but it was present in several prior versions. What is constant for all times I have seen the problem is that a normal TX happens if the failed TX is stopped and immediately re-started. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Double click on decode unresponsive?
With WSJT-X 2.1.0 and this group of decodes displayed in "Band activity" : 135600 -3 0.2 991 ~ CQ KD5FOY EM12 135600 -16 0.6 2207 ~ AE4CC N4HAI -04 30m 135615 -14 0.1 2240 ~ <...> 9M2TO -18 << 30m 135630 -8 0.2 990 ~ CQ KD5FOY EM12 135630 -18 0.1 1638 ~ CQ KB8SRX EN82 30m 135700 -8 0.2 991 ~ CQ KD5FOY EM12 135700 -12 0.6 2207 ~ AE4CC N4HAI -04 Double click on 9M2TO gives no response but double click on any other decode line moves that decode to "RX Frequency", moves the RX cursor, and generates appropriate messages. Why is 9M2TO unresponsive? The transmitting stations call, frequency, and signal report are known. A knowledge of who 9M2TO was in QSO with should not be needed since CQ calls are moved to "RX Frequency". Is lack of response to a double click on 9M2TO decode intended operation? In this case 9M2TO was also unresponsive in JTAlertX. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Incorrect FT8 auto-sequence WSJT-X v2.1.0
I don't expect Auto Seq to be perfect and I know I'm responsible for ensuring my transmitted message is appropriate. However, I though this incorrect Auto Seq may be of interest to the developers. 132045 Tx 2520 ~ CQ K3WYC DM33 132115 Tx 2520 ~ CQ K3WYC DM33 132145 Tx 2520 ~ CQ K3WYC DM33 132200 -16 0.1 2520 ~ K3WYC K5PA -20 132215 Tx 2520 ~ K5PA K3WYC R-16 132245 Tx 2520 ~ K5PA K3WYC R-16 132315 Tx 2520 ~ K5PA K3WYC R-16 132345 Tx 2520 ~ CQ K3WYC DM33 132415 Tx 2520 ~ CQ K3WYC DM33 132430 -12 0.1 2433 ~ K3WYC K5PA RRR 132445 Tx 2520 ~ K5PA K3WYC R-12 << 132500 -13 0.1 2433 ~ K3WYC K5PA RRR 132515 Tx 2520 ~ K5PA K3WYC 73 132530 -12 0.1 2433 ~ K3WYC K5PA 73 << If WSJT-X was aware an incomplete QSO was being continued the correct response would have been 73. If WSJT-X thought a new QSO was starting then the reply should have been "report" not "R report" since no report had been received in this new QSO. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RX freq cursor position anomaly
WSJT-X ver 2.1.0 64 bit has an anomaly with RX frequency cursor positioning that I had not noticed in ver 2.0.1. I call CQ with "Hold TX freq", "Call 1st", and "Auto Seq" enabled. WSJT-X auto replies to a caller who is not at my TX frequency. Sometimes my RX cursor moves immediately to the caller's frequency, sometimes it moves later during the QSO, sometimes it never moves at all. Shouldn't the RX frequency cursor move to the caller's frequency as soon as WSJT-X has decided this is the "first caller" and starts to auto-sequence the QSO? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] OmniRIg integration update
I had previously reported that OmniRig was pausing during the poling sequence and this caused WSJT-X ver 2.1.0 to issue a rig control fault. I found out that I was not running the latest version of OmniRig.exe. The reported test results were for OmniRig.exe file version 1.19.0.246. I installed the current version, 1.19.0.282, and now see different results. After an initial test run of over 6 hours there were no periods of data loss that exceeded 1 second. However, this version has a new anomaly with WSJT-X ver 2.1.0, 64 bit. The frequency resolution test is not completed when WSJT-X is started. This leaves the rig on the wrong frequency. E.g.: WSJT-X closed which takes TS-590S out of split 0:05:41.294 New IF - IF00014074000 0037502000; 0:05:41.297 New TX freq=14074000 0:05:41.298 split offset = 0 TS-590S is now 14.074 simplex WSJT-X is restarted: 0:06:12.855 New IF - IF00014074055 0037502000; 0:06:12.858 New RX freq=14074055 0:06:12.859 New TX freq=14074055 0:06:12.860 split offset = 0 0:06:12.871 New FA - FA00014074055; TS-590S is now simplex with wrong TX and RX frequencies Select band 20 m: 0:08:42.157 New FA - FA00014074000; 0:08:42.448 New IF - IF00014074000 0037502001; 0:08:42.451 New RX freq=14074000 0:08:42.452 New TX freq=14073000 0:08:42.455 split offset = -1000 TS-590S is now ready for operation. OmniRig.exe file version can be found by displaying the running file properties using Windows task manager. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
"What values are you using for Poll and Timeout in OmniRig?" The values were declared in my post. Here they are again - poll 250, timeout 1000, Baud 38,400. I used my station controller to generate a 'scope trigger when TS-590 data was not refreshed within 500 (later changed to 600 ms). I now have multiple 'scope captures that show OmniRig polling sometimes has large deviations from the specified poll interval. In all these cases my TS-590S responded to every poll that was issued by OmniRig. In the most recent event there was a period of 800 ms between routine polling frames instead of the specified 250 ms period. This event probably resulted in WSJT-X ver 2.1.0 loss of rig control but, with no time stamps in OmniRIg client or in the WSJT-X failure message, that correlation is not certain. It would be helpful if detail "Rig went offline" included a timestamp. OmniRIg recovers from these excessive poll periods but WSJT-X ver 2.1.0 does not. The same configuration of OmniRIg gives no issues with WSJT-X ver 2.0.1. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
"May I suggest that WSJT-X should be desensitized from these transient OmniRig fault reports by only responding if they persist for x seconds. " I made a temporary change to my controller code to flag TS-590 data fail if either IF, or FA, or FB is not received for 500 ms. This configuration detected data loss for the OmniRig dialog closure event. The data seems to indicate that data was lost for about 500.3 ms (500+(25.910-25.626)). I cannot see why WSJT-X should fail for a data loss that short. 0:00:05.085 displaying L/C Set screen 0:00:25.626 Ken data not fresh 0:00:25.684 displaying Active Warnings screen 0:00:25.718 Kenwood Data Fail 0:00:25.719 Ken data not fresh 0:00:25.720 Ken data not fresh . . 0:00:25.815 Ken data not fresh 0:00:25.818 Ken data not fresh 0:00:25.821 New IF - IF00010136000 0037502001; 0:00:25.827 Ken data not fresh 0:00:25.829 Ken data not fresh 0:00:25.833 Ken data not fresh 0:00:25.835 Ken data not fresh 0:00:25.837 Ken data not fresh 0:00:25.840 Ken data not fresh 0:00:25.843 Ken data not fresh 0:00:25.847 Ken data not fresh 0:00:25.849 Ken data not fresh 0:00:25.852 Ken data not fresh 0:00:25.854 Ken data not fresh 0:00:25.858 Ken data not fresh 0:00:25.861 Ken data not fresh 0:00:25.865 Ken data not fresh 0:00:25.867 New FA - FA00010136000; 0:00:25.871 Ken data not fresh 0:00:25.873 Ken data not fresh 0:00:25.875 Ken data not fresh 0:00:25.878 Ken data not fresh 0:00:25.881 Ken data not fresh 0:00:25.884 Ken data not fresh 0:00:25.887 Ken data not fresh 0:00:25.890 Ken data not fresh 0:00:25.892 Ken data not fresh 0:00:25.896 Ken data not fresh 0:00:25.899 Ken data not fresh 0:00:25.903 Ken data not fresh 0:00:25.905 Ken data not fresh 0:00:25.908 Ken data not fresh 0:00:25.910 New FB - FB00010137000; 0:00:25.915 warning cleared 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
I have attempted to use WSJT-X ver 2.1.0 a few more times but continue to be plagued by rig control failure messages. I have found that WSJT-X rig control failures are associated with OmniRig Client declarations "Status: Rig not responding. However, OmniRig seems to issue these messages when when communication is still good. For example, with OmniRig Poll Int = 250 and Timeout = 1000, Baud 38400, simply opening the Client "Dialog" window and then closing it with "OK" will result in a "Rig not responding" message and WSJT-X rig control error. May I suggest that WSJT-X should be desensitized from these transient OmniRig fault reports by only responding if they persist for x seconds. Typical OmniRig Client Event report: Dialog VISIBLE Rig type: WSJT-X Dialog invisible Status: Rig is not responding Status: Rig is not responding Status: Rig is not responding Status: On-line Typical station controller log for WSJT-X recovery from loss of rig control: 1:06:53.976 New IF - IF00010136055 0037502001; 1:06:53.985 New FA - FA00010136055; 1:06:53.987 New RX freq=10136055 1:06:53.988 split offset = 945 1:06:54.300 New IF - IF00010136000 0037502001; 1:06:54.309 New FA - FA00010136000; 1:06:54.311 New RX freq=10136000 1:06:54.313 split offset = 1000 My station controller is currently set to alarm if TS-590 data is not received for 5 seconds. There is no alarm for events that cause WSJT-X ver 2.1.0 to abandon rig control. BTW - OmniRIg setting "Timeout" does not behave as I had expected. I expected it to re-try for timeout period and then, if no response received, declare rig not responding. What it actually does is send nothing for timeout period then resume polling by repeating the command that had no response.If it missed a reply that was actually sent then it cannot recover until timeout period has elapsed. None of this is an issue with WSJT-X ver 2.0.1. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Illegal auto mode?
"This is illegal software in the US and probably elsewhere, and should not be used, even with the added line "always attend to your transceive when using" this does not make it legal." What specific FCC regulations permit a single QSO to be auto sequenced but prohibit auto sequencing of 2 or more QSO? I had been under the impression that disallowing auto QSO sequencing was a preference of the developers so, if it is illegal, I'd appreciate a reference. I can legally allow an unlicensed operator to make my QSO but I can't allow a supervised computer to do it? Before you all jump on me - I have no interest in running an automatic QSO machine. I'm only interested in the regulatory aspect of this. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Rx Frequency window
"The RX window displays all decodes that contain your call sign. Is this what is happening to you?" Yes, exactly. It displays decodes of anyone calling me regardless of the frequency. Most times I'm in QSO with Asia on 40 m I am jumped on by several JA and it makes it difficult to follow the QSO I'm in.I appreciate that sometimes it may be useful to have all calling stations displayed in one place but I can't see any reason it would be useful while in QSO. Those calling stations can be found by clicking JTAlert or the Band Activity window if there is some reason to abandon the current QSO and work a station which is attempting to interrupt it. Is there any way to configure WSJT-X so the Rx Frequency window only displays decodes at the Rx Frequency? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Rx Frequency window
Normally the Rx Frequency window show decodes of signals at , or close to, the RX frequency cursor. However, if I am in QSO with a station who is transmitting at the RX frequency, all stations that call me, regardless of their frequency, are also displayed in the RX Frequency window. I find this to be a significant distraction from managing the proper exchanges for the current QSO. Why are decodes from stations not at the RX frequency displayed in the RX Frequency window? Is there any configuration option that would prevent this happening? Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Lid operators or bad design?
"That could lead to a long discussion on the impact of the use of the "Call 1st" option and whether it's deletion would encourage better opting practices. " Of course that should have read "better operating practices". Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Lid operators or bad design?
"IMO, when using FT8, I consider it rude and poor operating practice to call a station on their frequency, simply because the station is more likely to be able to decode multiple callers of they're spread out." That could lead to a long discussion on the impact of the use of the "Call 1st" option and whether it's deletion would encourage better opting practices. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Lid operators or bad design?
Everyone who uses WSJT-X for FT8 must have noticed the number of operators who answer a CQ and then, when the QSO is complete, call CQ on the same frequency. Are all these operators really stupid or are they being trapped by a weakness in the user interface design? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Contest confusion
" This thread is about "Contest confusion" " when a contester is sending only the required exchange of a Grid Square and his QSO partner is a non-contester using standard FT messages which include SNR. The non-contester may be confused if she doesn't receive an SNR from the contester. " No, I think you have missed the point. The point of the OP was that if a contester replies to a CQ clearly from a non-contester then that person, if not confused, should use the exchange expected by the person who called CQ. The person calling CQ becomes frustrated and goes QRT because the confused contesters are not able to follow the established protocol for a standard non-contest QSO. If you don't want to follow standard QSO protocol then don't answer a CQ from a non-contest station. At least part of the problem is caused by WSJT-X itself because it auto-sequences to "RRR" in response to "R grid" even though that instance of the application is not selected to contest mode. If the received message is not "R report" WSJT-X should continue to send the report and not auto-sequence to RRR. Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Contest confusion
I chose not to participate in the RTTY contest but still wished to make FT8 QSO on 6 meters. I called CQ K3WYC DM33 thus indicating I was not in the contest. Multiple stations answered me and replied to my report with "R grid". Since these stations provided no report they were not logged. There needs to be a better way of separating contest participants from those with no interest in the contest. The contest cannot be allowed to take over standard FT8 frequencies. (I am not anti-contest. I have worked many CW contests and a quite a few phone and RTTY contests. I simply choose not to use WSJT-X modes for contesting) 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
I installed and ran ver 2.1.0 32 bit. Like ver 2.1.0 64 bit, it runs the frequency test on startup. Ver 2.0.1 shows no evidence in my controller log of ever running this test. My tentative conclusion is that a test which did not run in ver 2.0.1 now runs in ver 2.1.0 and that test sometimes fails to execute correctly. I'm reverting to ver 2.0.1 for normal operation but will run additional tests on 2.1.0 if requested. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
"maybe your CAT serial baud rate is too low for this delay to encompass the first poll. Can you increase your CAT serial baud rate?" Bill, COM port baud is 38,400. I doubt the baud is the cause of the problem. Thanks for confirming this check was in earlier versions. That is significant because I found no evidence of this test in my controller log prior to yesterday morning when I started using ver 2.1.0.I think that shows this version of WSJT-X does not behave the same as earlier versions. I'm using the 64 bit version because the only reason for making the update was to get the faster decode processing. I currently have no interest in FT4. I just noticed that ver 2.1.0 runs this test each it starts but ver 2.0.1 does not seem to. I ran a test series in which I started ver 2.1.0 , checked my controller log, stopped ver 2.1.0, started ver 2.0.1, checked controller log , repeat 4 times. Each time ver 2.1.0 was started my controller log shows it changed VFO A. The controller log shows no activity when ver 2.0.1 is started. Typical log for ver 2.1.0 start: 119:06:46.683 New IF - IF7074055 0041502001; 119:06:46.695 New FA - FA7074055; 119:06:46.697 New RX freq=7074055 119:06:46.700 split offset = 445 119:06:47.330 New IF - IF7074000 0041502001; 119:06:47.343 New FA - FA7074000; 119:06:47.345 New RX freq=7074000 119:06:47.346 split offset = 500 I'll try the 32 bit version later in the day but I see no reason to use it instead of 2.0.1 32 bit. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
"You should also note that the frequency is immediately reset back to
where it was before the resolution test started.:
Bill,
I provided an example that showed the frequency was not reset to the pre-test
value. Here is another which shows the freq offset was applied to the receive
and transmit frequency and the frequency error persisted for about 12 minutes.
Note that data is only output to the log when a value changes:
2019-07-16 20:39:49 84:15:21.212 backlight off
2019-07-17 05:52:21 93:23:18.405 New IF - IF7074055
0041502001; RX freq +055
2019-07-17 05:52:21 93:23:18.408 backlight on
2019-07-17 05:52:21 93:23:18.420 New FA - FA7074055;
2019-07-17 05:52:21 93:23:18.422 New RX freq=7074055
2019-07-17 05:52:21 93:23:18.424 split offset = 945
2019-07-17 05:53:00 93:23:56.365 New IF - IF7075055
0041512101; Transmitting with +055 offset
2019-07-17 05:53:00 93:23:56.636 New VSWR - VSWR 1.00;
2019-07-17 05:53:00 93:23:56.721 New KPA_WS - ^WS140 010;
2019-07-17 05:53:00 93:23:56.754 New FB - FB7075055;
2019-07-17 05:53:00 93:23:57.387 New KPA_WS - ^WS150 010;
2019-07-17 05:53:03 93:24:00.079 New KPA_WS - ^WS152 010;
2019-07-17 05:53:04 93:24:00.405 New KPA_WS - ^WS000 000;
2019-07-17 05:53:04 93:24:00.595 New IF - IF7074055
0041502001;
2019-07-17 05:53:05 93:24:01.399 New TX freq=7075055
controller TX freq not computed while transmitting
2019-07-17 05:53:05 93:24:01.400 split offset = 1000
2019-07-17 05:53:05 93:24:01.401 KPA band verified
2019-07-17 05:53:11 93:24:08.406 New IF - IF7075055
0041512101; Transmitting with +055 offset
2019-07-17 05:53:12 93:24:08.799 New KPA_WS - ^WS140 010;
2019-07-17 05:53:13 93:24:09.806 New KPA_WS - ^WS150 010;
2019-07-17 05:53:16 93:24:12.825 New KPA_WS - ^WS027 000;
2019-07-17 05:53:17 93:24:13.165 New KPA_WS - ^WS000 000;
2019-07-17 05:53:17 93:24:13.287 New IF - IF7074055
0041502001; <<< receiving with +055 offset
2019-07-17 05:59:01 93:29:55.466 New IF - IF7075055
0041512101; <<< transmitting with +055 offset
2019-07-17 05:59:02 93:29:55.606 New KPA_WS - ^WS135 010;
2019-07-17 05:59:02 93:29:55.931 New KPA_WS - ^WS140 010;
2019-07-17 05:59:03 93:29:56.614 New KPA_WS - ^WS147 010;
2019-07-17 05:59:03 93:29:56.939 New KPA_WS - ^WS150 010;
2019-07-17 05:59:04 93:29:57.941 New KPA_WS - ^WS000 000;
2019-07-17 05:59:05 93:29:58.396 New IF - IF7074055
0041502001; <<< receiving with +055 offset
2019-07-17 06:05:46 93:36:35.718 New IF - IF7074052
0041502001; <<< receiving with +052 offset
2019-07-17 06:05:46 93:36:35.729 New FA - FA7074051;
<<< receiving with +051 offset
2019-07-17 06:05:46 93:36:35.732 New RX freq=7074051
2019-07-17 06:05:46 93:36:35.733 split offset = 1004
<<< result of combined TX and RX offsets
2019-07-17 06:05:46 93:36:36.052 New IF - IF7074046
0041502001; <<< yet another RX offset value
2019-07-17 06:05:46 93:36:36.062 New FA - FA7074046;
2019-07-17 06:05:46 93:36:36.064 New RX freq=7074046
2019-07-17 06:05:46 93:36:36.066 split offset = 1009
2019-07-17 06:05:46 93:36:36.379 New IF - IF7074056
0041502001;
2019-07-17 06:05:46 93:36:36.397 New FA - FA7074058;
<<< yet another RX offset value
2019-07-17 06:05:46 93:36:36.399 New RX freq=7074058
2019-07-17 06:05:46 93:36:36.400 split offset = 997
2019-07-17 06:05:47 93:36:36.911 New IF - IF7074058
0041502001;
2019-07-17 06:05:51 93:36:41.466 New IF - IF7074000
0041502001;
2019-07-17 06:05:51 93:36:41.477 New FA - FA7074000;
<<< RX freq back to correct value
2019-07-17 06:05:51 93:36:41.479 New RX freq=7074000
2019-07-17 06:05:51 93:36:41.480 split offset = 1055
2019-07-17 06:05:51 93:36:41.532 New FB - FB7075000;
<<< TX freq back to correct value
2019-07-17 06:05:51 93:36:41.535 New TX freq=7075000
2019-07-17 06:05:51 93:36:41.536 split offset = 1000
2019-07-17 06:14:02 93:44:47.913 New IF - IF7075000
0041512101; <<< transmitting with zero offset
2019-07-17 06:14:02 93:44:48.437 New KPA_WS - ^WS132 010;
2019-07-17 06:14:02 93:44:48.762 New KPA_WS - ^WS140 010;
2019-07-17 06:14:03 93:44:49.445 New KPA_WS - ^WS142 010;
2019-07-17 06:14:03 93:44:49.764 New KPA_WS - ^WS150 010;
2019-07-17 06:14:13 93:44:59.513 New KPA_WS - ^WS035 010;
2019-07-17 06:14:14 93:44:59.831 New KPA_WS - ^WS000 000;
2019-07-17 06:14:14 93:45:00.284 New IF - IF7074000
0041502001; <<< receiving with zero offset
2019-07-17 06:14:30 93:45:16.226 New IF
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
Well I think I have the answer to my question. The backlight on my controller times out after 15 minutes of no activity on the user interface and no changes in TS-590 data. I was alerted to an anomaly when the back light unexpectedly turned on. The data appears to show that WSJT-X made 2 frequency changes, presumably with the intention of testing the rig interface: 2019-07-17 16:54:17 104:19:42.598 backlight off 2019-07-17 17:05:11 104:30:31.127 New IF - IF00018100055 0041502001; 2019-07-17 17:05:11 104:30:31.131 backlight on 2019-07-17 17:05:11 104:30:31.138 New FA - FA00018100055; 2019-07-17 17:05:11 104:30:31.141 New RX freq=18100055 2019-07-17 17:05:11 104:30:31.142 split offset = 945 2019-07-17 17:05:11 104:30:31.447 New IF - IF0001810 0041502001; 2019-07-17 17:05:11 104:30:31.457 New FA - FA0001810; 2019-07-17 17:05:11 104:30:31.459 New RX freq=1810 2019-07-17 17:05:11 104:30:31.460 split offset = 1000 I would guess that this unnecessary test sometimes fails. I am competent to monitor my rig's frequencies and take full responsibility if they are not what I intended. Please give me the option to inhibit this check. 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
Not seen again while chasing 1A0C. Got him in the log with no WSJT-X issues. Will keep monitoring but, if it is a new WSJT-X issue, it seems to be infrequent. Would still like to know if anything changed in the OmniRig interface. Does WSJT-X intentionally shift the rig frequency to test control? 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes
This morning I installed and ran WSJT-X v2.1.0. In the short time I have been using it I have observed two spontaneous changes to my RX frequency and one spontaneous change to my TX frequency. No such changes were seen with ver 2.0.1 and the only thing that has changed in my environment is that WSJT-X ver 2.1.0 is running instead of ver 2.0.1. I'm using OmnRig to control my Kenwood TS-590S. The most event was recorded by my Kenwood/Elecraft interface controller and annotated as follows: "Spontaneous RX freq change WSJT-X ver 2.1.0 with OmniRig 2019-07-17 09:19:59 96:49:12.269 New IF - IF0001810 0041502001; << receiving 18100.000 2019-07-17 09:20:16 96:49:28.539 New IF - IF00018101000 0041512101; << transmitting 18101.000 2019-07-17 09:20:16 96:49:28.865 New IF - IF0001810 0041502001; << receiving 18100.000 2019-07-17 09:35:23 97:04:28.868 backlight off 2019-07-17 09:38:47 97:07:50.918 New IF - IF00018100055 0041502001; << spontaneous change. Now receiving on 18100.055 2019-07-17 09:38:47 97:07:50.921 backlight on 2019-07-17 09:38:47 97:07:50.928 New FA - FA00018100055; 2019-07-17 09:38:47 97:07:50.930 New RX freq=18100055 2019-07-17 09:38:47 97:07:50.931 split offset = 945 " (The record includes two time stamps. The first is MST, the second is time since controller reset. The controller can only read TS-590 frequencies and cannot set them.) What, if anything, was changed in the OmniRig interface between ver 2.0.1 and ver 2.1.0? Are any other OmniRig users seeing this anomaly? Thanks and 73, Andy, k3wyc ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] TX freqs change while xmttg (Joe Taylor)
"Yes, you can move the Tx frequency marker on the waterfall while transmitting. If you stay within the same 500 Hz segment, the result will be what you probably expected. Otherwise, probably not. ... the purpose of that checkbox is to enable (or not) sending new VFO settings to your radio while it is transmitting. This is necessary for EME Doppler tracking on microwave bands." Joe, I do not understand your reply. In 1.8.0-rc1, when "Allow frequency changes while transmitting" is not checked, and when working rig split, it is not possible to move the TX cursor on widegraph nor is it possible to scroll the TX frequency on the main window. In short, neither the audio frequency nor the Rig TX VFO frequency can be changed. That is the way I expected it to work. Only if split is not enabled is it possible to change the TX audio frequency while transmitting. That causes no problems because it is not possible to get the audio frequency and TX VFO frequency out of "registration". 500 Hz segments have no meaning if split is not enabled. Has this behavior been changed in later code? Thanks and 73, Andy k3wyc -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] distance in log (Bill Somerville) (Jim Brown)
"Yes, that is common behavior in DXKeeper -- it does the same with QSOs imported as ADIF from contest loggers like N1MMPlus." This was discussed in the DXLabs group here: https://groups.yahoo.com/neo/groups/dxlab/conversations/messages/169659 It was clear that in this case it was JTAlertX, not DXK, that was "harvesting " previous QSO data. Let's continue the conversation using the DXLabs thread, or on the new HamApps group, if any follow up is needed. 73, Andy k3wyc -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] distance in log (Bill Somerville)
Please disregard my previous message. I had not correctly remembered the results of my test. Here is what I reported in the DXLAbs group: "I ran another test this morning using the same call but with a completely different grid. This seems a reasonable simulation of someone operating from an alternate QTH. The grid was logged to DXK as I had entered it in WSJT-X. But, and it's a big but, the station data for entity, state, country, CQ zone and ITU zone was harvested from a previous QSO." 73, Andy k3wyc ____ From: ANDY DURBIN <a.dur...@msn.com> Sent: Thursday, August 3, 2017 6:50 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: distance in log (Bill Somerville) " Do you have a logging application that does not accept grid squares?" JTALertX will override the WSJT-X logged grid and use a completely different grid from a previous QSO in DXK log. It's a nasty defect that I hope will be fixed. Until then I manually enter the grid to comment line on all my QSO. 73, Andy k3wyc -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] distance in log (Bill Somerville)
" Do you have a logging application that does not accept grid squares?" JTALertX will override the WSJT-X logged grid and use a completely different grid from a previous QSO in DXK log. It's a nasty defect that I hope will be fixed. Until then I manually enter the grid to comment line on all my QSO. 73, Andy k3wyc -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] r7812 "Enable TX" off and 73 sent
"we did talk about labeling the button "Auto Tx" or such rather than "Enable Tx" to make it clearer. The tooltip describes it better as Auto Tx." Well there is perhaps still time to do that. I changed it in my private build months ago. I have a green "Auto TX" indicator that is cleared by logging the QSO. Much more intuitive, in this operator's opinion, than the way it is implemented in the released build. The only thing I would change in my private build is that logging would not clear Auto TX until the end of the current transmission. 73, Andy k3wyc -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
