Topics

WSJTX intermittent stoppage thread


Dave AA6YQ
 

Please find attached debugging/error log in case it'll help determine why WSJTX and DX are giving rig errors.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.

+ What is the text of the error messages you are encountering?

73,

Dave, AA6YQ


Ed W2LCQ
 

I can’t understand why the email client is not conveying the snipped copy of the WSJT-X error report. I will have to wait until it reappears before I can transcribe it and send it to you. It essentially says the program lost contact with the radio (DXC) and offers to retry or reconfigure the radio. I’ll get back to you with the exact wording. I will also try to reproduce the error with WSJT-X working with N1MM+. 
I have an expensive shielded USB cable with two large ferrite toroids and 3/4 twists of cable between my Windows 10 machine and IC-7300  I don’t experience RFI with DXL or N1MM+.  

Best, Ed

73 de W2LCQ, Ed Jones

Frankford Radio Club
BUG 204 - TBDXC 1337 - CWops (Life) 701 - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC (Life) 51 Instructor - ARRL - New York County (Manhattan) FN30AT DXCC WAS

The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane.” ...Nicola Tesla



On Jan 15, 2021, at 12:32 PM, Dave AA6YQ <aa6yq@...> wrote:

Please find attached debugging/error log in case it'll help determine why WSJTX and DX are giving rig errors.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.

+ What is the text of the error messages you are encountering?

       73,

                Dave, AA6YQ








Dave AA6YQ
 

+ AA6YQ comments below

I can’t understand why the email client is not conveying the snipped copy of the WSJT-X error report.

+ It is this Discussion Group that is configured to not convey attachments. We have a fixed storage allocation, attachments count against that allocation, and I'd rather not spend my time deleting attachments from the message archives.

I will have to wait until it reappears before I can transcribe it and send it to you. It essentially says the program lost contact with the radio (DXC) and offers to retry or reconfigure the radio. I’ll get back to you with the exact wording. I will also try to reproduce the error with WSJT-X working with N1MM+.
I have an expensive shielded USB cable with two large ferrite toroids and 3/4 twists of cable between my Windows 10 machine and IC-7300 I don’t experience RFI with DXL or N1MM+.

+ No two applications have the same timing, so the absence of problematic behavior with one is not meaningful with respect to another.

+ Have you configured Windows to not power down the USB port used to communicate with your IC-7300?

https://www.dxlabsuite.com/dxlabwiki/PreventUSBPortPowerDown

+ Have you configured your anti-malware to consider WSJT-X and each of your applications to be "safe"?

73,

Dave, AA6YQ


g4wjs
 

Hi Ed,

when you get a WSJT-X pop up error message box you can hit Ctrl+C immediately it appears, that will copy the full text of the message including the details to the Windows clipboard. As such it is suitable for pasting into a reply here or elsewhere, no need for screen captures, photographs, or other means that would require wasteful, and disallowed here, attachments.

73
Bill
G4WJS.

On 15/01/2021 17:48, Ed W2LCQ via groups.io wrote:
I can’t understand why the email client is not conveying the snipped copy of the WSJT-X error report. I will have to wait until it reappears before I can transcribe it and send it to you. It essentially says the program lost contact with the radio (DXC) and offers to retry or reconfigure the radio. I’ll get back to you with the exact wording. I will also try to reproduce the error with WSJT-X working with N1MM+. 
I have an expensive shielded USB cable with two large ferrite toroids and 3/4 twists of cable between my Windows 10 machine and IC-7300  I don’t experience RFI with DXL or N1MM+.  

Best, Ed

73 de W2LCQ, Ed Jones

Frankford Radio Club
BUG 204 - TBDXC 1337 - CWops (Life) 701 - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC (Life) 51 Instructor - ARRL - New York County (Manhattan) FN30AT DXCC WAS

The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane.” ...Nicola Tesla



On Jan 15, 2021, at 12:32 PM, Dave AA6YQ <aa6yq@...> wrote:

Please find attached debugging/error log in case it'll help determine why WSJTX and DX are giving rig errors.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.

+ What is the text of the error messages you are encountering?

       73,

                Dave, AA6YQ



--
73

Bill

G4WJS.


 

---------------------------
WSJT-X
---------------------------
Rig Control Error
---------------------------
Do you want to reconfigure the radio interface?
---------------------------
OK   Retry   Cancel   Configurations...   Show Details...   
---------------------------
DX Lab Suite Commander rig did not respond to PTT: ON
---------------------------

That's the alarm that ULTIMATELY comes up in a WSJT-x window for me.  Not sure if Ed's is identical, but I would guess.  But prior to the alarm WSJT behaves strangely and will stop going through transmit cycles until you hit "Enable Tx" button again.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.
--- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.


Evan. Sippert
KS1PPY


 

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.
--- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.
  ^^^^ And by alarm, I mean the WSJTx alarm.  I know DXLab may not have seen alarm, but I figured the debug MAY be helpful to see what DX was seeing prior to WSJT alarms. It may not be in which case, apologies.

Evan L.  Sippert
KS1PPY


g4wjs
 

Hi Evan, and Dave,

that message is because despite WSJT-X requested DX Lab Suite Commander key the rig, but subsequent attempts to verify that status did not show the rig was in Tx mode.

73
Bill
G4WJS.

On 15/01/2021 19:10, Evan L. Sippert KS1PPY wrote:
---------------------------
WSJT-X
---------------------------
Rig Control Error
---------------------------
Do you want to reconfigure the radio interface?
---------------------------
OK   Retry   Cancel   Configurations...   Show Details...   
---------------------------
DX Lab Suite Commander rig did not respond to PTT: ON
---------------------------

That's the alarm that ULTIMATELY comes up in a WSJT-x window for me.  Not sure if Ed's is identical, but I would guess.  But prior to the alarm WSJT behaves strangely and will stop going through transmit cycles until you hit "Enable Tx" button again.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred. --- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.

Evan. Sippert
KS1PPY



--
73

Bill

G4WJS.


Kurt Ekman
 

I am using WSTJ + JTAlert with an IC-7300. Same error message come now and then. Do not know the reason.

Kurt OH2NJN

Den fre 15 jan. 2021 21:30g4wjs <bill.8@...> skrev:

Hi Evan, and Dave,

that message is because despite WSJT-X requested DX Lab Suite Commander key the rig, but subsequent attempts to verify that status did not show the rig was in Tx mode.

73
Bill
G4WJS.

On 15/01/2021 19:10, Evan L. Sippert KS1PPY wrote:
---------------------------
WSJT-X
---------------------------
Rig Control Error
---------------------------
Do you want to reconfigure the radio interface?
---------------------------
OK   Retry   Cancel   Configurations...   Show Details...   
---------------------------
DX Lab Suite Commander rig did not respond to PTT: ON
---------------------------

That's the alarm that ULTIMATELY comes up in a WSJT-x window for me.  Not sure if Ed's is identical, but I would guess.  But prior to the alarm WSJT behaves strangely and will stop going through transmit cycles until you hit "Enable Tx" button again.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred. --- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.

Evan. Sippert
KS1PPY



--
73

Bill

G4WJS.


Mike Flowers
 

>>> By default, Windows enables the power saving feature on all USB ports known as USB Selective Suspend.

 

https://helpdesk.flexradio.com/hc/en-us/articles/204290929-How-to-Disable-Power-Management-for-USB-connected-Devices

 

You may want to check the power management status of your CAT Control USB ports.   When I first started using CAT Control this caused me problems until I was tipped off to this Windows ‘feature’.

 

- 73 and good DX de Mike, K6MKF, NCDXC Secretary

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Kurt Ekman
Sent: Friday, January 15, 2021 12:20
To: DXLab@groups.io
Subject: Re: [DXLab] WSJTX intermittent stoppage thread

 

I am using WSTJ + JTAlert with an IC-7300. Same error message come now and then. Do not know the reason.

 

Kurt OH2NJN

 

Den fre 15 jan. 2021 21:30g4wjs <bill.8@...> skrev:

Hi Evan, and Dave,

 

that message is because despite WSJT-X requested DX Lab Suite Commander key the rig, but subsequent attempts to verify that status did not show the rig was in Tx mode.

 

73
Bill
G4WJS.

 

On 15/01/2021 19:10, Evan L. Sippert KS1PPY wrote:

---------------------------

WSJT-X

---------------------------

Rig Control Error

---------------------------

Do you want to reconfigure the radio interface?

---------------------------

OK   Retry   Cancel   Configurations...   Show Details...   

---------------------------

DX Lab Suite Commander rig did not respond to PTT: ON

---------------------------


That's the alarm that ULTIMATELY comes up in a WSJT-x window for me.  Not sure if Ed's is identical, but I would guess.  But prior to the alarm WSJT behaves strangely and will stop going through transmit cycles until you hit "Enable Tx" button again.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred. --- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.

Evan. Sippert
KS1PPY

 


--
73

Bill

G4WJS.


dxradio33
 

I would ask myself a question under the circumstances noted below.  Have I ever experienced ANY artifacts of RFI in my present configuration?  Have I heard my own CW in the form of RFI beside any sidetone  when running power in my headset?  Things of this nature.  This problem totally smacks of RFI to me.

 

Hope you get it sorted.

 

73’s

Joe K8FC

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Friday, January 15, 2021 13:34
To: DXLab@groups.io
Subject: Re: [DXLab] WSJTX intermittent stoppage thread

 

Hi Ed,

 

when you get a WSJT-X pop up error message box you can hit Ctrl+C immediately it appears, that will copy the full text of the message including the details to the Windows clipboard. As such it is suitable for pasting into a reply here or elsewhere, no need for screen captures, photographs, or other means that would require wasteful, and disallowed here, attachments.

 

73
Bill
G4WJS.

 

On 15/01/2021 17:48, Ed W2LCQ via groups.io wrote:

I can’t understand why the email client is not conveying the snipped copy of the WSJT-X error report. I will have to wait until it reappears before I can transcribe it and send it to you. It essentially says the program lost contact with the radio (DXC) and offers to retry or reconfigure the radio. I’ll get back to you with the exact wording. I will also try to reproduce the error with WSJT-X working with N1MM+. 

I have an expensive shielded USB cable with two large ferrite toroids and 3/4 twists of cable between my Windows 10 machine and IC-7300  I don’t experience RFI with DXL or N1MM+.  

Best, Ed

 

73 de W2LCQ, Ed Jones

 

Frankford Radio Club

BUG 204 - TBDXC 1337 - CWops (Life) 701 - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC (Life) 51 Instructor - ARRL - New York County (Manhattan) FN30AT DXCC WAS



The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane.” ...Nicola Tesla

 

 



On Jan 15, 2021, at 12:32 PM, Dave AA6YQ <aa6yq@...> wrote:

Please find attached debugging/error log in case it'll help determine why WSJTX and DX are giving rig errors.

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.

+ What is the text of the error messages you are encountering?

       73,

                Dave, AA6YQ

 


--
73

Bill

G4WJS.


Dave AA6YQ
 

+ AA6YQ comments below

that message is because despite WSJT-X requested DX Lab Suite Commander key the rig, but subsequent attempts to verify that status did not show the rig was in Tx mode.

+ The errorlog Evan sent me shows that

1. He is running an Icom transceiver whose CI-V address is 94 and that is constantly reporting spectrum data (94 is the default CI-V address for an IC-7300)

2. Commander received a single TCP message containing 3 directives:

2a. set VFO B to a specified frequency and enable split

2b. start transmitting

2c. report the transceiver's transmit/receive status

3. Commander's response to the "report the transceiver's transmit/receive status" directive was "not transmitting" because while the "start transmitting" directive had been processed, the "transmit" CCI-V command was still in Commander's outgoing queue, and thus had not yet been issued to the radio, much less executed and reported by the radio.

4. Commander received a single TCP message containing 2 directives:

4a. stop transmitting

4b. report the transceiver's transmit/receive status


+ Evan: to what is the "Command interval" set in the Radio panel on the General tab of Commander's Configuration window? For optimal performance with an IC-7300 and Commander's Spectrum-Waterfall Display enabled, I suggest enabling the Radio panel's "Verify CI-V command acceptance" option and setting the "Command Interval" to 25.

+ Bill: sending Commander 3 directives simultaneously, the second of which is "start transmitting" and the third of which of which is "report RX/TX status", and then reporting an error if the "report RX/TX status" isn't yet "TX" will cause trouble with radios whose rate of command processing is not fast. Commander will inform the user if a command execution error occurs; having WSJT-X duplicate this is unnecessary.

73,

Dave, AA6YQ


Ed W2LCQ
 

Thanks Bill that is great info. Right now I’m running WSJT-X with N1MM+ taking DXK out of the equation.  After 40 minutes and 8 FT-8 contacts I’ve not encountered the stoppage. I’m going to run this way for a longer period of time and great number of QSOs. Dave K2XR has been helping me with this. 

Kind regards, Ed

73 de W2LCQ, Ed Jones

Frankford Radio Club
BUG 204 - TBDXC 1337 - CWops (Life) 701 - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC (Life) 51 Instructor - ARRL - New York County (Manhattan) FN30AT DXCC WAS

The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane.” ...Nicola Tesla



On Jan 15, 2021, at 2:19 PM, Evan L. Sippert KS1PPY <evan.sippert@...> wrote:

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.
--- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.
  ^^^^ And by alarm, I mean the WSJTx alarm.  I know DXLab may not have seen alarm, but I figured the debug MAY be helpful to see what DX was seeing prior to WSJT alarms. It may not be in which case, apologies.

Evan L.  Sippert
KS1PPY


Dave / NR1DX
 

Ed

Just because it "runs" with N1MM and not with DXLab will not prove anything. I actually had a reverse problem where things ran with DXLab but not with N1MM ...turned out to be RF in the shack was interfering with the timing of data handshakes

Dave
NR1DX

On 1/15/2021 6:22 PM, Ed W2LCQ via groups.io wrote:
Thanks Bill that is great info. Right now I’m running WSJT-X with N1MM+ taking DXK out of the equation.  After 40 minutes and 8 FT-8 contacts I’ve not encountered the stoppage. I’m going to run this way for a longer period of time and great number of QSOs. Dave K2XR has been helping me with this.

Kind regards, Ed

73 de W2LCQ, Ed Jones

Frankford Radio Club
BUG 204 - TBDXC 1337 - CWops (Life) 701 - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC (Life) 51 Instructor - ARRL - New York County (Manhattan) FN30AT DXCC WAS

“/The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane.” ...Nicola Tesla/



On Jan 15, 2021, at 2:19 PM, Evan L. Sippert KS1PPY <evan.sippert@gmail.com> wrote:

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.
--- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.
  ^^^^ And by alarm, I mean the WSJTx alarm.  I know DXLab may not have seen alarm, but I figured the debug MAY be helpful to see what DX was seeing prior to WSJT alarms. It may not be in which case, apologies.

Evan L.  Sippert
KS1PPY
--
Dave Manuals@ArtekManuals.com www.ArtekManuals.com
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


 

+ Evan: to what is the "Command interval" set in the Radio panel on the General tab of Commander's Configuration window? For optimal performance with an IC-7300 and Commander's Spectrum-Waterfall Display enabled, I suggest enabling the Radio panel's "Verify CI-V command acceptance" option and setting the "Command Interval" to 25.

The 7300 had been set to interval 50.  I've changed to 25, and enabled the "Verify CI-V command acceptance" checkmark on the general tab.  Will let you know how that goes.

As a curiosity I have DX Commander configured for multiple radios.  I have an ICOM 7100 who's interval in the Multiradio was also set to 25.  I changed them both to 25 based on information received so far, but Is there any reason I shouldn't set them to that?

Thanks, and great info!

Evan L. Sippert
KS1PPY


Dave AA6YQ
 

+ AA6YQ comments below
The 7300 had been set to interval 50.  I've changed to 25, and enabled the "Verify CI-V command acceptance" checkmark on the general tab.  Will let you know how that goes.

+ If operation is reliable with a Command Interval of 25, reduce it to 15. If that's reliable, reduce it to 10.

+ It's not my primary radio, but I successfully run my IC-7300 with the Spectrum Waterfall window active and a Command Interval of 10.

As a curiosity I have DX Commander configured for multiple radios.  I have an ICOM 7100 who's interval in the Multiradio was also set to 25.  I changed them both to 25 based on information received so far, but Is there any reason I shouldn't set them to that?

+ The IC-7100 is an older -- and thus slower -- radio than the IC-7300. Use the same approach recommended above: start at 200, check for reliability, cut the Command Interval in half, and repeat.

      73,

           Dave, AA6YQ

 


Dave K2XR
 

Late to the party, but appears I should have either have jumped in earlier or stayed out altogether but here we are.

   DXDave  Ed (and I) were not trying to prove anything at this stage of our investigation. Merely looking to isolate the reason for the errors being thrown to whatever is the cause.  Since   DXL and N1MM use the same command and control mechanism. specifically using udp sockets to do the dirty work,  If switching to N1MM as the radio interface yielded the same errors, then we would head in the WSJT ( actually the hamlib.dll ) direction.  But if the errors ceased, then we would head in the DXL direction. They have ceased using the N1MM wrapper (so far).

YQDAVE

RFI is not an issue, the errors persist even with little to no output.

USB port sleeping is not an issue such a state is not possible in the time between functional and the error being thrown.

I think I saw one of the others involved was using true split as opposed to the FAKE IT split method.  This was implied by the command sequence you interpreted.  Some rigs are known to take several seconds to perform the real split operation, and this will cause the appearance of the same timeout message.

Ed LCQ's system is stable using N1MM as the WSJT rig interface, but gets a timeout from hamlib.dll using  the Spot Collector / Commander mechanism.  All UDP ports/sockets are identical in both configurations.

Dave, I believe you are on the right track when you mentioned to Bill about commanding transmit and immediately checking for tx engagement.

Ed is NOT reading waterfall data from the 7300 in either configuration  which can sometimes result in signalling latencies. His hardware is up to the task for either piece of software.

If you want him to try something, I will help him accomplish whatever task you desire.  Ed is a Mac user, not a PC guy and I have been walking him through the configuration and usage of the various tools.

DXDave glad you were able to sort out your RFI issues.  73

    XRDave

On 1/15/2021 7:09:25 PM, Dave / NR1DX wrote:
Ed

Just because it "runs" with N1MM and not with DXLab will not prove anything. I actually had a reverse problem where things ran with DXLab but not with N1MM ...turned out to be RF in the shack was interfering with the timing of data handshakes

Dave
NR1DX

On 1/15/2021 6:22 PM, Ed W2LCQ via groups.io wrote:
Thanks Bill that is great info. Right now I’m running WSJT-X with N1MM+ taking DXK out of the equation.  After 40 minutes and 8 FT-8 contacts I’ve not encountered the stoppage. I’m going to run this way for a longer period of time and great number of QSOs. Dave K2XR has been helping me with this.

Kind regards, Ed

73 de W2LCQ, Ed Jones

Frankford Radio Club
BUG 204 - TBDXC 1337 - CWops (Life) 701 - SKCC 5474T - FISTS 12294 - QCWA 33438 - LICWC (Life) 51 Instructor - ARRL - New York County (Manhattan) FN30AT DXCC WAS

“/The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane.” ...Nicola Tesla/



On Jan 15, 2021, at 2:19 PM, Evan L. Sippert KS1PPY <evan.sippert@gmail.com> wrote:

+ The errorlog you sent me contains no reports of errors; it was created because you enabled Commander's "Log debugging info" option, not because an actual error occurred.
--- Understood, but I turned it on to capture debug during the course of normal ops until the alarm occurred. Then stopped the debug and sent the log.
  ^^^^ And by alarm, I mean the WSJTx alarm.  I know DXLab may not have seen alarm, but I figured the debug MAY be helpful to see what DX was seeing prior to WSJT alarms. It may not be in which case, apologies.

Evan L.  Sippert
KS1PPY


Dave AA6YQ
 

+ AA6YQ comments below
Dave, I believe you are on the right track when you mentioned to Bill about commanding transmit and immediately checking for tx engagement

+ No transceiver that I know publishes a spec that guarantees that within X millisecond receiving a "Transmit" CAT command, it will have begun transmitting and will respond affirmatively" to a "Report your RX/TX state" CAT command.

+ From the time when WSJT-X directs Commander to direct the transceiver to start transmitting until the time when Commander can respond affirmatively to a "Report transceiver's RX/TX state" direct from WSJT-X, there are multiple steps:

1. finish processing previous directives from WSJT-X

2. send a "Transmit" CAT command to the radio

3. send a "report your RX/TX state" CAT command to the radio and receive an affirmative response; Commander continuously cycles through a sequence of "Report Frequency", "Report Mode", "Report Split", "Report RX/TX State", "Report RX Bandwidth", "Report S-meter" commands to track the transceiver's full state); so there is a delay from when the transceiver has actually begun transmitting until Commander becomes aware of that state change.

+ Thus WSJT-X must tolerate a relatively wide range of response times to a "direct transceiver to start transmitting" directive. As I remarked earlier, Commander would inform the user if it could not execute a directive from WSJT-X, so there is no reason for WSJT-X to double-check that the RX-to-TX change actually occurred.

+ In the errorlog I examined, Commander received 3 directives from WSJT-X in a single TCP transmission. Commander had to execute the first two directives ("set VFO B to frequency F and enable split", and "start transmitting") before it could execute third "report RX/TX status" directive - so WSJT-X premature concluded that the "start transmitting" directive was not successfully executed. It may be that the reception of the 3 directives in a single TCP transmission is responsible for the additional delay that results in the erroneous conclusion by WSJT-X.

     73,

             Dave, AA6YQ

 

 

 

 


g4wjs
 

Hi Dave and all,

comments in line below.

On 16/01/2021 06:28, Dave AA6YQ wrote:
+ AA6YQ comments below
Dave, I believe you are on the right track when you mentioned to Bill about commanding transmit and immediately checking for tx engagement

+ No transceiver that I know publishes a spec that guarantees that within X millisecond receiving a "Transmit" CAT command, it will have begun transmitting and will respond affirmatively" to a "Report your RX/TX state" CAT command.

+ From the time when WSJT-X directs Commander to direct the transceiver to start transmitting until the time when Commander can respond affirmatively to a "Report transceiver's RX/TX state" direct from WSJT-X, there are multiple steps:

1. finish processing previous directives from WSJT-X

2. send a "Transmit" CAT command to the radio

3. send a "report your RX/TX state" CAT command to the radio and receive an affirmative response; Commander continuously cycles through a sequence of "Report Frequency", "Report Mode", "Report Split", "Report RX/TX State", "Report RX Bandwidth", "Report S-meter" commands to track the transceiver's full state); so there is a delay from when the transceiver has actually begun transmitting until Commander becomes aware of that state change.

+ Thus WSJT-X must tolerate a relatively wide range of response times to a "direct transceiver to start transmitting" directive. As I remarked earlier, Commander would inform the user if it could not execute a directive from WSJT-X, so there is no reason for WSJT-X to double-check that the RX-to-TX change actually occurred.

WSJT-X will make repeated attempts to verify that Commander has managed to switch the rig to transmit, it does this for up to one second, which is the minimum time we allow in this case for the rig to transition to transmit (and likewise to receive). If it is taking longer than that then the sending or receiving of messages will be compromised.

Exactly how does Commander inform WSJT-X that a directive has not been executed? Note it is WSJT-X that needs to know this since it is WSJT-X that is going to start/stop sending audio. In the case of sending audio, failure to ensure that the rig has transitioned to transmit before sending audio is likely to do expensive damage due to hot-switching. Telling the user that the directive has not been executed promptly is no use for that requirement. I see no other practical way of avoiding hot switching other than polling Commander that the rig is actually in transmit mode (or receive for the less critical switch back to Rx).

+ In the errorlog I examined, Commander received 3 directives from WSJT-X in a single TCP transmission. Commander had to execute the first two directives ("set VFO B to frequency F and enable split", and "start transmitting") before it could execute third "report RX/TX status" directive - so WSJT-X premature concluded that the "start transmitting" directive was not successfully executed. It may be that the reception of the 3 directives in a single TCP transmission is responsible for the additional delay that results in the erroneous conclusion by WSJT-X.

I refute this claim, WSJT-X will have asked for a report of RX/TX status repeatedly for up to one second before issuing the message about Commander not responding to PTT assertion. Either Commander blocked the reply to the first query for a second or more, or you have missed further report RX/TX status directives that followed on. Either way the transition to transmit could not be verified within one second.

     73,

             Dave, AA6YQ


--
73

Bill

G4WJS.


Dave K2XR
 

To add to the existing. When the error occurs, the rig is indeed in transmit. In fact when WSJT exits, it remains in transmit and the user is forced to reset the rig with power cycling or engage software to force it into RX mode.

So one might  work on the premise that some process is not reporting the change in TX status  on successive requests, or in a timely fashion.

   XR

On 1/16/2021 6:40:52 AM, g4wjs wrote:
Hi Dave and all,

comments in line below.

On 16/01/2021 06:28, Dave AA6YQ wrote:
+ AA6YQ comments below
Dave, I believe you are on the right track when you mentioned to Bill about commanding transmit and immediately checking for tx engagement

+ No transceiver that I know publishes a spec that guarantees that within X millisecond receiving a "Transmit" CAT command, it will have begun transmitting and will respond affirmatively" to a "Report your RX/TX state" CAT command.

+ From the time when WSJT-X directs Commander to direct the transceiver to start transmitting until the time when Commander can respond affirmatively to a "Report transceiver's RX/TX state" direct from WSJT-X, there are multiple steps:

1. finish processing previous directives from WSJT-X

2. send a "Transmit" CAT command to the radio

3. send a "report your RX/TX state" CAT command to the radio and receive an affirmative response; Commander continuously cycles through a sequence of "Report Frequency", "Report Mode", "Report Split", "Report RX/TX State", "Report RX Bandwidth", "Report S-meter" commands to track the transceiver's full state); so there is a delay from when the transceiver has actually begun transmitting until Commander becomes aware of that state change.

+ Thus WSJT-X must tolerate a relatively wide range of response times to a "direct transceiver to start transmitting" directive. As I remarked earlier, Commander would inform the user if it could not execute a directive from WSJT-X, so there is no reason for WSJT-X to double-check that the RX-to-TX change actually occurred.

WSJT-X will make repeated attempts to verify that Commander has managed to switch the rig to transmit, it does this for up to one second, which is the minimum time we allow in this case for the rig to transition to transmit (and likewise to receive). If it is taking longer than that then the sending or receiving of messages will be compromised.

Exactly how does Commander inform WSJT-X that a directive has not been executed? Note it is WSJT-X that needs to know this since it is WSJT-X that is going to start/stop sending audio. In the case of sending audio, failure to ensure that the rig has transitioned to transmit before sending audio is likely to do expensive damage due to hot-switching. Telling the user that the directive has not been executed promptly is no use for that requirement. I see no other practical way of avoiding hot switching other than polling Commander that the rig is actually in transmit mode (or receive for the less critical switch back to Rx).

+ In the errorlog I examined, Commander received 3 directives from WSJT-X in a single TCP transmission. Commander had to execute the first two directives ("set VFO B to frequency F and enable split", and "start transmitting") before it could execute third "report RX/TX status" directive - so WSJT-X premature concluded that the "start transmitting" directive was not successfully executed. It may be that the reception of the 3 directives in a single TCP transmission is responsible for the additional delay that results in the erroneous conclusion by WSJT-X.

I refute this claim, WSJT-X will have asked for a report of RX/TX status repeatedly for up to one second before issuing the message about Commander not responding to PTT assertion. Either Commander blocked the reply to the first query for a second or more, or you have missed further report RX/TX status directives that followed on. Either way the transition to transmit could not be verified within one second.

     73,

             Dave, AA6YQ


--
73

Bill

G4WJS.


Dave AA6YQ
 

# more AA6YQ comments below

WSJT-X will make repeated attempts to verify that Commander has managed to switch the rig to transmit, it does this for up to one second, which is the minimum time we allow in this case for the rig to transition to transmit (and likewise to receive). If it is taking longer than that then the sending or receiving of messages will be compromised.

# In this case, Commander's "RX" response to the "report RX/TX status" directive came more than one second after the "TX" directive.

Exactly how does Commander inform WSJT-X that a directive has not been executed?

# I posted that Commander will inform the user if a directive fails, not that it would inform WSJT-X.

Note it is WSJT-X that needs to know this since it is WSJT-X that is going to start/stop sending audio. In the case of sending audio, failure to ensure that the rig has transitioned to transmit before sending audio is likely to do expensive damage due to hot-switching. Telling the user that the directive has not been executed promptly is no use for that requirement. I see no other practical way of avoiding hot switching other than polling Commander that the rig is actually in transmit mode (or receive for the less critical switch back to Rx).


+ In the errorlog I examined, Commander received 3 directives from WSJT-X in a single TCP transmission. Commander had to execute the first two directives ("set VFO B to frequency F and enable split", and "start transmitting") before it could execute third "report RX/TX status" directive - so WSJT-X premature concluded that the "start transmitting" directive was not successfully executed. It may be that the reception of the 3 directives in a single TCP transmission is responsible for the additional delay that results in the erroneous conclusion by WSJT-X.

I refute this claim, WSJT-X will have asked for a report of RX/TX status repeatedly for up to one second before issuing the message about Commander not responding to PTT assertion.

# In this case, the response to the "report RX/TX status" direct came more than a second after the "TX" directive, so the WSJT-X behavior shown in the errorlog is consistent with your description.

Either Commander blocked the reply to the first query for a second or more, or you have missed further report RX/TX status directives that followed on. Either way the transition to transmit could not be verified within one second.

# The errorlog shows a system running very slowly, failing to implement the switch from RX to TX within 1 second as required by WSJT-X. One component of that slowness was receiving 3 directives in a single TCP message; WSJT-X assumed that Commander was processing the "TX" directive it had sent, when Commander was still processing the "set VFO B and enable split" directive that preceded it.

73,

Dave, AA6YQ