Hamlib/WSJT-X issue with SDRPlusPlus

[x31415926]

Run into a compatibility issue between SDRPlusPlus and WSJT-x (Hamlib). I detailed my findings in AlexandreRouma/SDRPlusPlus#573, but, in short, it appears that according to the manual netrigctl should only send the VFO string if vfo_mode is set, not when vfo_option OR vfo_mode is.

Code snippet from https://github.com/Hamlib/Hamlib/blob/master/rigs/dummy/netrigctl.c#L121
if (rig->state.vfo_opt || priv->rigctld_vfo_mode) {

The consequence of the current implementation is that a server responding to the chk_fvo command with CHKVFO 0 still receives the vfo string. If this is somehow expected, then I would imagine there should be a recommended response the software implementer can use to indicate the server doesn't support that option .

This may also be the root cause for #930

[mdblack98]

Can you compile yourself? If so, try changing this line around 267 in netrigctl.c and see if it fixes the problem.    if (sscanf(buf, "CHKVFO %d", &priv->rigctld_vfo_mode) == 1)    {        rig->state.vfo_opt = priv->rigctld_vfo_mode; On Saturday, April 8, 2023 at 06:51:45 PM CDT, x31415926 ***@***.***> wrote: Run into a compatibility issue between SDRPlusPlus and WSJT-x (Hamlib). I detailed my findings in AlexandreRouma/SDRPlusPlus#573, but, in short, it appears that according to the manual netrigctl should only send the VFO string if vfo_mode is set, not when vfo_option OR vfo_mode is. Code snippet from https://github.com/Hamlib/Hamlib/blob/master/rigs/dummy/netrigctl.c#L121 if (rig->state.vfo_opt || priv->rigctld_vfo_mode) { The consequence of the current implementation is that a server responding to the chk_fvo command with CHKVFO 0 still receives the vfo string. If this is somehow expected, then I would imagine there should be a recommended response the software implementer can use to indicate the server doesn't support that option . This may also be the root cause for #930 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[x31415926]

Can you compile yourself? If so, try changing this line around 267 in netrigctl.c and see if it fixes the problem.    if (sscanf(buf, "CHKVFO %d", &priv->rigctld_vfo_mode) == 1)    {        rig->state.vfo_opt = priv->rigctld_vfo_mode; >

1. I am not setup to test this fast/easily, unfortunately.
2. I understand what your suggestion will accomplish, but if you do just that you'd still leave the door open for set_vfo_opt having the same problem, no?

So, why not just change
if (rig->state.vfo_opt || priv->rigctld_vfo_mode) {

into

if (priv->rigctld_vfo_mode) {

?

[mdblack98]

No... Here's a zip file with a package that has this fix to test. https://www.dropbox.com/s/tgeouohpw8x7ezt/bin.zip?dl=0 Mike W9MDB On Sunday, April 9, 2023 at 12:15:56 AM CDT, x31415926 ***@***.***> wrote: Can you compile yourself? If so, try changing this line around 267 in netrigctl.c and see if it fixes the problem.    if (sscanf(buf, "CHKVFO %d", &priv->rigctld_vfo_mode) == 1)    {        rig->state.vfo_opt = priv->rigctld_vfo_mode; > - I am not setup to test this fast/easily, unfortunately. - I understand what your suggestion will accomplish, but if you do just that you'd still leave the door open for set_vfo_opt having the same problem, no? So, why not just change if (rig->state.vfo_opt || priv->rigctld_vfo_mode) { into if (priv->rigctld_vfo_mode) { ? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[x31415926]

Thanks, but I run into a different error which may be [similar to] #1186? As far as I can see from the sdrpp logging this occurs on open, before any chk_vfo / F commands, so cannot confirm the fix.

Hamlib error:   2:rig.c(7511):async_data_handler_start entered
async_data_handler_start: async data support disabled since async_data_enabled=0
  2:rig.c(7518):async_data_handler_start returning(0) 
rig.c(262):add_opened_rig returning2(0) 
rig_open: 000000004d029f0c rs->comm_state==1?=1
  2:rig.c(6110):rig_get_powerstat entered
../../src/src/rig.c(6130) trace
netrigctl_get_powerstat called
netrigctl_transaction: called len=15
rig_flush: called for network device
network_flush called
write_block(): TX 15 bytes, method=2
0000    5c 67 65 74 5f 70 6f 77 65 72 73 74 61 74 0a        \get_powerstat. 
read_string_generic called, rxmax=1024 direct=1, expected_len=1
read_string_generic(): RX 7 characters, direct=1
0000    52 50 52 54 20 31 0a                                RPRT 1.         
  2:rig.c(6135):rig_get_powerstat returning(0) 
rig_open: rig power is off, use --set-conf=auto_power_on if power on is wanted
Rig is not powered on
Rig is not powered on
 while opening connection to rig

[mdblack98]

SDR++ is not emulating  rigctld correctly....but this should fix the problem.They really need to emulate a real rig like a TS-480 to prevent future problems like this. https://www.dropbox.com/s/tgeouohpw8x7ezt/bin.zip?dl=0 Mike W9MDB On Sunday, April 9, 2023 at 03:16:04 PM CDT, x31415926 ***@***.***> wrote: Thanks, but I run into a different error which may be [similar to] #1186? As far as I can see from the sdrpp logging this occurs on open, before any chk_vfo / F commands, so cannot confirm the fix. Hamlib error: 2:rig.c(7511):async_data_handler_start entered async_data_handler_start: async data support disabled since async_data_enabled=0 2:rig.c(7518):async_data_handler_start returning(0) rig.c(262):add_opened_rig returning2(0) rig_open: 000000004d029f0c rs->comm_state==1?=1 2:rig.c(6110):rig_get_powerstat entered ../../src/src/rig.c(6130) trace netrigctl_get_powerstat called netrigctl_transaction: called len=15 rig_flush: called for network device network_flush called write_block(): TX 15 bytes, method=2 0000 5c 67 65 74 5f 70 6f 77 65 72 73 74 61 74 0a \get_powerstat. read_string_generic called, rxmax=1024 direct=1, expected_len=1 read_string_generic(): RX 7 characters, direct=1 0000 52 50 52 54 20 31 0a RPRT 1. 2:rig.c(6135):rig_get_powerstat returning(0) rig_open: rig power is off, use --set-conf=auto_power_on if power on is wanted Rig is not powered on Rig is not powered on while opening connection to rig — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[x31415926]

SDR++ is not emulating  rigctld correctly....but this should fix the problem.They really need to emulate a real rig like a TS-480 to prevent future problems like this. https://www.dropbox.com/s/tgeouohpw8x7ezt/bin.zip?dl=0 Mike W9MDB

I have copied these files onto a wsjtx2.6 instance and the original issue is fixed.

Do you mind expressing the minimal requirements for emulating rigctld so that an implementer (like sdrpp) can adhere to? The reason I am asking is mostly for capturing and documenting the expectations on chk_vfo (the original issue)?

[mdblack98]

There is no documented interface.  rigctld is not an API designed to be used by anything other than rigctl and the netrigctl backend.  It's overly complex to try to talk to it completely.Any other software should pick a rig to emulate -- TS-2000 and TS-480 are popular.  Then any program that can talk to a TS-2000 or 480 can also talk to that program via a serial-2-tcp adaptor.  For example FLRig to talk to SDR++ via TCP with no problem but will probably never talk to it as a rigctld emulator. With that said....generally all calls do not respond with "RPRT" unless there's an error. Mike W9MDB On Monday, April 10, 2023 at 06:57:17 PM CDT, x31415926 ***@***.***> wrote: SDR++ is not emulating  rigctld correctly....but this should fix the problem.They really need to emulate a real rig like a TS-480 to prevent future problems like this. https://www.dropbox.com/s/tgeouohpw8x7ezt/bin.zip?dl=0 Mike W9MDB I have copied these files onto a wsjtx2.6 instance and the original issue is fixed. Do you mind expressing the minimal requirements for emulating rigctld so that an implementer (like sdrpp) can adhere to? The reason I am asking is mostly for capturing and documenting the expectations on chk_vfo (the original issue)? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>