Using TCI, SDR rig stays in TX after TX watchdog timeout

[K7MDL2]

Very reproducible here, most reliably when WSJT-X (3.0.2) and SDR app are on the same machine, Looking at the logs

1. When calling CQ and the WSJT-X watchdog timeout expires, it goes to TX very briefly and 0.01sec later it triggers the timeout and goes to RX
2. The switch to RX message is somehow missed by 3 SDR apps tested.
3. 0.3 seconds later, the SDR app response is received that it is in TX mode. Presumably for the initial TX message that the SDR rig in now in TX. I assume WSJT-X sees this as a choice by the SDR app to go into TX and so leaves in TX status, sending no tone, just leaves the Rig and amps downstream in TX mode.
4. I have to hit the MOX button to stop TX.

SDR apps used.
Thetis v2.0.3.15
piHPSDR v3 built yesterday.
deskHPSDR built yesterday
Any combination of Windows and Linux, same issue noted.

I have some logs from WSJT-X and piHPSDR and Thetis below.

For this test I set the timeout at 2M, but 5Min and 6M do the dame thing.
At local time 21:16 the timeout occurs in the WSJT-X logs you see the RX->TX->RX commands followed by TX received from the App. I do not yet know if all of these actually hit the wire. I can try Wireshark if needed.

pihpsdr_log.txt
wsjtx_log.txt
WSJT-X_RigControl.log
wsjtx_syslog.log

Here is the Thetis TCI specific log output. No time stamps in this one. I hit the Thetis MOX to go back to RX. I will file a bug on the WSJT-X github site.

app_focus:false;
app_focus:true;
app_focus:false;
trx:0,false;
volume:-47.4;
app_focus:true;
trx:0,true;
volume:-30.0;
< trx:0,true,tci
trx:0,false;
volume:-47.4;
< trx:0,false,tci
trx:0,true;
volume:-30.0;
< trx:0,true,tci
trx:0,false;
volume:-47.4;
< trx:0,false,tci
trx:0,true;
volume:-30.0;
< trx:0,true,tci
trx:0,false;
volume:-47.4;
< trx:0,false,tci

[K7MDL2]

DL1YCF examined the WSJT-X code and suspected that this only happens on even minutes. All my tests were on even minutes as it happens. Today I retested with both periods.

Tx-Even periods almost always stay in TX at timeout.
Tx-Odd periods have never resulted in TZX stuck on after many tries.

It seems the WD timer is examined on full minute boundaries so Tx-Odd escapes the WD timer expiring just as TX is started. The rig went to TX as commanded, and the rig returned a TX switch event which arrives in WSJT-X after the WD triggered TX->RX switch was sent. WSJT-X then assumes the Rig chose to go to TX manually (or really, it makes no assumptions, it just follows the rig status).

--> It is suggested the WD timeout trigger be delayed well past expected TX/RX switchovers to avoid a race condition.

More analysis is in this thread - dl1ycf/pihpsdr#123

[K7MDL2]

Same result with WSJT-X 3.1.0 Improved Plus. Tx-Even with WD timeout results in Tx left on fairly often. No audio out thus no RF out.