Stopping modem on a second RX only machine stops rig transmit leaving main freedv showing PTT red.

[barjac]

I am using rigctld to talk to the radio with a rigctld instance running on the main machine. A second machine tracks the radio band/freq via it's rigctld LAN connection to the main machine. Occasionally I want to change a setting in the instance of freedv running on the second machine which is monitoring a web SDR.

On Sunday while in RX I wanted to start reporting on the second machine which I did without problem, however when I was later transmitting I wanted to stop that reporting. This can only be done with the modem stopped, so I stopped that modem and continued talking without realizing that the rig had released PTT. The main instance of freedv was still showing red TX.

This behaviour is fully reproducible

This may be a hamlib problem related to my particular radio.

However if the reporting could be turned on/off without stopping the modem then this would be an adequate workaround although not a cure for the core issue.

FreeDV is current master on main machine @ #12de5 FreeDV on second (RPi4) is from PR build @ #7550d Kenwood TS-450S Hamlib is a snapshot taken at 13-Apr-2024 from upstream #789d863f9

[tmiw]

Would setting PTT Via to None on the second machine fix this for you? I'm not necessarily sure that forcing TX off when stopping the modem isn't desired behavior normally (unless I'm not fully understanding the scenario).

[barjac]

Would setting PTT Via to None on the second machine fix this for you?

This is already set as well as the setting to force 'RX Only'

I'm not necessarily sure that forcing TX off when stopping the modem isn't desired behavior normally (unless I'm not fully understanding the scenario).

The second machine is there purely to monitor remote SDRs via internet. It is connected only over LAN to the main machine (running rigctld) to track freq and mode.

Starting the modem on the second machine causes the normal beeps from the rig as it grabs the freq and mode to correctly track, this upsets nothing regarding the main transmission. It is only when stopping the modem on the second machine that it stops the ongoing TX at the rig, it leaves the main freedv instance apparently unaware that this has happened.

I would not expect the second machine to affect the rig PTT state set by the main machine when set as 'RX only' and 'PTT none'.

I appreciate that neither freedv instance has any knowledge of the other and also does not know what the 'other' machine last did to the rig, other than by checking its current state. ;)

[barjac]

Testing further after rebuilding freedv from git master using build_linux.sh on the RPi4 I find that with 'PTT uses:' set to 'None (RX Only)' the Test PTT button actually puts the rig into TX for about a second before dropping it back to RX!

Below is the verbose terminal output from the RPi from launch, then start modem, then stop modem. (with main machine in TX until it is stopped by the 'Stop' of the RPi modem)

freedv.log

The output of: cat freedv.log|grep ptt ...is interesting:

[baz@jackodesktop freedv]$ cat freedv.log|grep ptt rig_token_lookup called for ptt_pathname rig_confparam_lookup called for ptt_pathname rig_set_conf: ptt_pathname='192.168.1.65:4532' rig_token_lookup called for ptt_type rig_confparam_lookup called for ptt_type rig_set_conf: ptt_type='NONE' netrigctl_open: ptt_type='0x1'(1) 1:rig.c(3016):rig_set_ptt entered netrigctl_set_ptt called vfo=currVFO, ptt=0, ptt_type=5 1:rig.c(3301):rig_set_ptt returning(0) [baz@jackodesktop freedv]$

[barjac]

Oops! Damn! Sorry! I just realized that my test and log were not from the latest build on the RPi4 machine. I ran: freedv --verbose .... in error instead of: ./freedv --verbose .... /o\

Re-testing with the real git master version on the RPi4 I find that this is now fixed and stopping and restarting the modem in the second machine no longer affects the rig TX state.

So, closing this rather sheepishly ...sorry for the noise and thanks as always for your super efforts. :)