QRP-Labs QDX IF command parsing buggy

[madpsy]

I'm using a QRP-Labs QDX which emulates TS-440. When requesting PTT state from rigctl (sending command 't') it returns 0 (RX) even when still transmitting.

It appears that the 440 protocol returns accurate PTT state from 'P8' of the 'IF' command as per the spec. I'm going to suggest that hamlib reads PTT state from this, rather than return 0 as it does now.

Discussion here: https://groups.io/g/QRPLabs/topic/95922381?p=Created,,,20,1,0,0::recentpostdate/sticky,,,20,2,0,95922381,previd=1672274690459582723,nextid=1672093401297648786

I might be wrong but this is as far as I've gotten in terms of debug.

[mdblack98]

That's exactly what it should be reading. Unless the QRP Labs rig is not providing the IC10 formatted IF string which is 33 bytes long. Please place this file as described below https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0     C:\Users\[username]\AppData\Local\WSJT-X     The WSJT-X_Rigcontrol.log file will be in the same location For Linux put it in       ~/.config     The WSJT-X_Rigcontrol.log file will be here:     ~/.local/share/WSJT-X For MacOS put it in     /Users/[username]/Library/Preferences   Restart WSJT-X and duplicate the problem. Shut down WSJT-X Then send me the WSJT-X_RigControl.log file Mike W9MDB On Wednesday, December 28, 2022 at 06:59:13 PM CST, madpsy ***@***.***> wrote: I'm using a QRP-Labs QDX which emulates TS-440. When requesting PTT state from rigctl (sending command 't') it returns 0 (RX) even when still transmitting. It appears that the 440 protocol returns accurate PTT state from 'P8' of the 'IF' command as per the spec. I'm going to suggest that hamlib reads PTT state from this, rather than return 0 as it does now. Discussion here: https://groups.io/g/QRPLabs/topic/95922381?p=Created,,,20,1,0,0::recentpostdate/sticky,,,20,2,0,95922381,previd=1672274690459582723,nextid=1672093401297648786 I might be wrong but this is as far as I've gotten in terms of debug. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mdblack98]

Actually you said you are using rigctl so please do this.... rigctl -m 2002 -r COM1 -s 4800 -vvvvv -Z t T 1 t T 0 >log.txt 2>&1 Adjust port and baud to suit. Send me the log.txt file. Mike W9MDB On Wednesday, December 28, 2022 at 06:59:13 PM CST, madpsy ***@***.***> wrote: I'm using a QRP-Labs QDX which emulates TS-440. When requesting PTT state from rigctl (sending command 't') it returns 0 (RX) even when still transmitting. It appears that the 440 protocol returns accurate PTT state from 'P8' of the 'IF' command as per the spec. I'm going to suggest that hamlib reads PTT state from this, rather than return 0 as it does now. Discussion here: https://groups.io/g/QRPLabs/topic/95922381?p=Created,,,20,1,0,0::recentpostdate/sticky,,,20,2,0,95922381,previd=1672274690459582723,nextid=1672093401297648786 I might be wrong but this is as far as I've gotten in terms of debug. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[madpsy]

I've not done quite what you've asked but thought this may be more useful. These are to/from the radio itself.

IF;                   IF00014074000     +00000000003000000 ;
TX;
IF;                   IF00014074000     +00000000013000000 ;
RX;
IF;                   IF00014074000     +00000000003000000 ;

Note that this issue has nothing to do with WSJT-X - that works fine. It sends TX; and RX; and behaves as expected. The issue is when other software queries rigctld for get_ptt it returns 0. I know this works fine with a TS-2000 (at least a radio emulating one).

[madpsy]

log.txt

Here's the startup log

[mdblack98]

So they are not really emulating a TS-440 as the IF command is 33 bytes and not 37 bytes.  The CAT manual for the IC-10 shows a possibility of 37 bytes but everybody does 33 and the other 4 bytes are optional (and unused). I guess I can change Hamlib to allow for their broken emulation. On Thursday, December 29, 2022 at 05:17:40 AM CST, madpsy ***@***.***> wrote: log.txt Here's the startup log — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[madpsy]

Well spotted. I mean if you're confident their implementation is broken I'm sure they wouldn't mind fixing it. Just don't want to end up in a back and forth over who's righ - though that's exactly why there's a spec after all.

If you want me to raise a bug with them I'm more than happy to - likewise happy for a workaround in Hamlab. Your call 👍

[mdblack98]

2022-12-29:11:16:28.261651: 0000 49 46 3b IF;
2022-12-29:11:16:28.261728: read_string called, rxmax=50
2022-12-29:11:16:28.274911: read_string(): RX 38 characters
2022-12-29:11:16:28.275010: 0000 49 46 30 30 30 31 34 30 37 34 30 30 30 20 20 20 IF00014074000
2022-12-29:11:16:28.275092: 0010 20 20 2b 30 30 30 30 30 30 30 30 30 30 33 30 30 +0000000000300
2022-12-29:11:16:28.275169: 0020 30 30 30 30 20 3b 0000 ;
2022-12-29:11:16:28.275245: ic10_cmd_trim: incoming data_len is '37'
2022-12-29:11:16:28.275321: ic10_cmd_trim: data['36'] is ' '
2022-12-29:11:16:28.275397: ic10_cmd_trim: For i='37' data_len is now '36'
2022-12-29:11:16:28.275473: ic10_cmd_trim: finished loop.. i='36' data_len='36' data[i-1]='0'

[mdblack98]

Well they got it completely wrong.  I'm adding patch to fix their problem.  They should also fix their end. I notice you are using TS-480 instead of TS-440 too.  TS-480 uses the TX command so be sure to use the TS-440. Normal IC10 response is 33 bytes and not 36 bytes.  If you follow the IC10 format P13/P14/P15 are not used and they stuck 3 bytes in for P13/P14/P15.  In addition to that P14 is two bytes instead of 1 so they even got that wrong and their reply would be 37 bytes instead of 36 if they got P14 "correct". Instead of this: IF00014074000     +00000000003000000 ; Should be: IF00014074000     +00000000003000 ; 2022-12-29:11:16:27.129285: 0000    49 46 3b                                            IF;              2022-12-29:11:16:27.129318: read_string called, rxmax=50 2022-12-29:11:16:27.142335: read_string(): RX 38 characters 2022-12-29:11:16:27.142389: 0000    49 46 30 30 30 31 34 30 37 34 30 30 30 20 20 20     IF00014074000    2022-12-29:11:16:27.142425: 0010    20 20 2b 30 30 30 30 30 30 30 30 30 30 33 30 30       +0000000000300 2022-12-29:11:16:27.142458: 0020    30 30 30 30 20 3b                                   0000 ;           2022-12-29:11:16:27.142495: ic10_cmd_trim: incoming data_len is '37' 2022-12-29:11:16:27.142533: ic10_cmd_trim: data['36'] is ' ' 2022-12-29:11:16:27.142566: ic10_cmd_trim: For i='37' data_len is now '36' On Thursday, December 29, 2022 at 11:15:50 AM CST, madpsy ***@***.***> wrote: Well spotted. I mean if you're confident their implementation is broken I'm sure they wouldn't mind fixing it. Just don't want to end up in a back and forth over who's righ - though that's exactly why there's a spec after all. If you want me to raise a bug with them I'm more than happy to - likewise happy for a workaround in Hamlab. Your call 👍 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[madpsy]

Thanks I'll raise a bug their end too. I'm using '2002' which is correct to the best of my knowlege as per rigctld --list:

2002  Kenwood                TS-440S                 20200407.0      Stable      RIG_MODEL_TS440

madpsy@rocket:~$ rigctld -m 2002 -r /dev/ttyACM1 -s 9600 -t 51111 

[mdblack98]

Try the latest master repo.  Should work now. Mike W9MDB On Thursday, December 29, 2022 at 11:15:50 AM CST, madpsy ***@***.***> wrote: Well spotted. I mean if you're confident their implementation is broken I'm sure they wouldn't mind fixing it. Just don't want to end up in a back and forth over who's righ - though that's exactly why there's a spec after all. If you want me to raise a bug with them I'm more than happy to - likewise happy for a workaround in Hamlab. Your call 👍 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[madpsy]

Will do after work, thanks in advance.

[madpsy]

Just FYI I've no idea what these lines are all about:

2022-12-29:11:16:27.128634: kenwood_open: not the right driver apparently (found 2002, asked for 2028, checked TS-440S)
2022-12-29:11:16:27.128668: kenwood_open: found match 020
2022-12-29:11:16:27.128701: kenwood_open: not the right driver apparently (found 2002, asked for 2046, checked TS-440S)

That's when running with -m 2002

[mdblack98]

That because the QRP ID; command is responding with ID020; which is a TS-480.  It  should be ID004; which is a TS-440 if that's what they are emulating.  That and fix their IF command to return 33 bytes instead of 36. The TS-480 won't work since it seems their TX; command is broken too as you noted before.  You sure TX; returns TX0; all the time? Mike W9MDB On Thursday, December 29, 2022 at 12:02:33 PM CST, madpsy ***@***.***> wrote: Just FYI I've no idea what these lines are all about: 2022-12-29:11:16:27.128634: kenwood_open: not the right driver apparently (found 2002, asked for 2028, checked TS-440S) 2022-12-29:11:16:27.128668: kenwood_open: found match 020 2022-12-29:11:16:27.128701: kenwood_open: not the right driver apparently (found 2002, asked for 2046, checked TS-440S) That's when running with -m 2002 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[madpsy]

I'm not 100% - would need to test. The good news is your fix is indeed working a treat so much appreciated. Shall link to this bug when I raise one on their end.

Many thanks.