1. Topics
  2. Unsupported command sent to IC-746

locked Unsupported command sent to IC-746 #Cat_RigControl

Dean Souleles
 

Hi -

Potential bug report for WSJT / Hamlib  for and IC-746

I have written an IC-746 emulator that runs on and Arduino for home-brew transceivers - available here:  https://github.com/kk4das/IC746CAT

It implements the rig side of the ICOM CIV protocol.  It worked fine with WSJTX until some time after version 2.2.2.   I was notified by one of the folks that is using my library that the get a "rig control error" when using the my library with version WSJTX 2.5.1.

The issue is caused  by WSJTX sending CIV command 25  "Send/read the selected or unselected VFO frequency" which is not implemented (or at least not documented) on an IC-746.   My firmware sends an ACK for unknown commands - I've changed it to send a NACK which allows WSJTX to connect and operate without error, but the software should probably not be sending undocumented and likely unimplemented commands to a rig.

73,
Dean
KK4DAS
Bill Somerville
 

On 22/10/2021 17:01, Dean Souleles wrote:
Hi -

Potential bug report for WSJT / Hamlib  for and IC-746

I have written an IC-746 emulator that runs on and Arduino for home-brew transceivers - available here:  https://github.com/kk4das/IC746CAT

It implements the rig side of the ICOM CIV protocol.  It worked fine with WSJTX until some time after version 2.2.2.   I was notified by one of the folks that is using my library that the get a "rig control error" when using the my library with version WSJTX 2.5.1.

The issue is caused  by WSJTX sending CIV command 25  "Send/read the selected or unselected VFO frequency" which is not implemented (or at least not documented) on an IC-746.   My firmware sends an ACK for unknown commands - I've changed it to send a NACK which allows WSJTX to connect and operate without error, but the software should probably not be sending undocumented and likely unimplemented commands to a rig.

73,
Dean
KK4DAS

Dean,

why does your software send a valid command response to a command you are not emulating? The correct response to an unrecognized command is "FE FE E0 ra FA FD", where ra is the radio CI-V address. This "NG" command is documented in every Icom CI-V manual ever produced with the description "the radio has received a message, but it could not perform the specified operation".

The use of this by CAT software is crucial where new commands have been introduced in firmware updates.

73
Bill
G4WJS.
Dean Souleles
 

Thanks Bill,

I had been sending an OK message for unexpected / undocumented commands but I changed it to the NG message and the current version of WSJTX now connects without the "rig control error".  I do have reasonable responses for all of the commands documented in the IC-746 manual. 

I take your point taken on the expected response for unsupported CIV commands and have made that change. Just an observation -  the IC-746  firmware hasn't changed in over 10 years and likely never will and this command is not supported by the rig - so not sure if there are any other downstream effects.   I can't imagine how complex it is to keep hamlib working with the large number of rigs and wide variations.  The vendor documentation on CAT protocols often is ambiguous.  You all collectively do an amazing job.  

Also, not that it signifies anything in this case - but I haven't had this issue with any other software.

73,
Dean
KK4DAS

Thanks for the quick reply,

73,
Dean
KK4DAS
Bill Somerville
 

On 22/10/2021 18:36, Dean Souleles wrote:
Thanks Bill,

I had been sending an OK message for unexpected / undocumented commands but I changed it to the NG message and the current version of WSJTX now connects without the "rig control error".  I do have reasonable responses for all of the commands documented in the IC-746 manual.

I take your point taken on the expected response for unsupported CIV commands and have made that change. Just an observation -  the IC-746  firmware hasn't changed in over 10 years and likely never will and this command is not supported by the rig - so not sure if there are any other downstream effects.   I can't imagine how complex it is to keep hamlib working with the large number of rigs and wide variations.  The vendor documentation on CAT protocols often is ambiguous.  You all collectively do an amazing job.

Also, not that it signifies anything in this case - but I haven't had this issue with any other software.

73,
Dean
KK4DAS

Thanks for the quick reply,

73,
Dean
KK4DAS
Hi Dean,

all understood, it is the Hamlib developers and contributors decision when to share functionality between similar rigs and when to duplicate similar code for each rig. Neither path is straightforward, hi.

73
Bill
G4WJS.
Dean Souleles
 

Hi Bill,

So I *thought* sending NG in response to the undocumented cmd 25 for the IC-746 fixed my issue with WSJTX connecting to my IC-746 emulation but now I am getting a "Rig Failure" message that says "Command rejected by Rig" which it is!   

I can figure out what a reasonable response is a get it working but it seems like neither a GOOD or NG response will satisfy Hamlib.  Not sure how to report an issue to the Hamlib team - I'll have to look around.

73,
Dean
KK4DAs
Michael Black
 

If you send me the debug logs I can probably figure out what you're doing wrong.

It sends a 0x25 command the 1st time get_freq is called and if it fails then disables the command...but it does not return and error when it does that.  It will then use the 0x03 command to do it as seen below from that point on.

In the debug log it looks like this
2021-11-10:04:19:54.695824: icom_get_freq: using vfo=None
2021-11-10:04:19:54.695828: frame.c(408):icom_transaction entered
2021-11-10:04:19:54.695833: icom_transaction: cmd=0x25, subcmd=0x00, payload_len=0
2021-11-10:04:19:54.695837: frame.c(139):icom_one_transaction entered
2021-11-10:04:19:54.695843: frame.c(54):make_cmd_frame entered
2021-11-10:04:19:54.695847: frame.c(88):make_cmd_frame return(7)
2021-11-10:04:19:54.695851: rig_flush: called for serial device
2021-11-10:04:19:54.695855: serial.c(645):serial_flush entered
2021-11-10:04:19:54.695860: read_string called, rxmax=4095
2021-11-10:04:19:54.697686: serial.c(705):serial_flush return(0)
2021-11-10:04:19:54.697768: write_block(): TX 7 bytes
2021-11-10:04:19:54.697777: 0000    fe fe 58 e0 25 00 fd                                ..X.%..
2021-11-10:04:19:54.697784: frame.c(458):read_icom_frame entered
2021-11-10:04:19:54.697789: read_string called, rxmax=80
2021-11-10:04:19:54.711644: read_string(): RX 7 characters
2021-11-10:04:19:54.711666: 0000    fe fe 58 e0 25 00 fd                                ..X.%..
2021-11-10:04:19:54.711670: frame.c(495):read_icom_frame return(7)
2021-11-10:04:19:54.711675: frame.c(458):read_icom_frame entered
2021-11-10:04:19:54.711678: read_string called, rxmax=80
2021-11-10:04:19:54.727645: read_string(): RX 6 characters
2021-11-10:04:19:54.727667: 0000    fe fe e0 58 fa fd                                   ...X..
2021-11-10:04:19:54.727671: frame.c(495):read_icom_frame return(6)
2021-11-10:04:19:54.727676: frame.c(336):icom_one_transaction return(-9)
2021-11-10:04:19:54.727680: icom_transaction: failed: Command rejected by the rig
frame.c(495):read_icom_frame return(6)
frame.c(336):icom_one_transaction return(-9)
icom_transaction: failed: Command rejected by the rig
frame.c(495):read_icom_frame return(6)
frame.c(336):icom_one_transaction return(-9)
frame.c(336):icom_one_transaction return(-9)
2021-11-10:04:19:54.727683: frame.c(438):icom_transaction return(-9)
2021-11-10:04:19:54.727687: icom_get_freq: rig does not support 0x25 CI-V cmd
2021-11-10:04:19:54.727690: icom.c(1531) trace
2021-11-10:04:19:54.727694: set_vfo_curr: vfo=None, curr_vfo=None
2021-11-10:04:19:54.727697: set_vfo_curr: curr_vfo now=None
2021-11-10:04:19:54.727701: icom.c(9087):set_vfo_curr return(0)
2021-11-10:04:19:54.727717: frame.c(408):icom_transaction entered
2021-11-10:04:19:54.727720: icom_transaction: cmd=0x03, subcmd=0xffffffff, payload_len=0
2021-11-10:04:19:54.727723: frame.c(139):icom_one_transaction entered
2021-11-10:04:19:54.727727: frame.c(54):make_cmd_frame entered
2021-11-10:04:19:54.727730: frame.c(88):make_cmd_frame return(6)
2021-11-10:04:19:54.727734: rig_flush: called for serial device
2021-11-10:04:19:54.727737: serial.c(645):serial_flush entered
2021-11-10:04:19:54.727741: read_string called, rxmax=4095
2021-11-10:04:19:54.728915: serial.c(705):serial_flush return(0)
2021-11-10:04:19:54.728939: write_block(): TX 6 bytes
2021-11-10:04:19:54.728945: 0000    fe fe 58 e0 03 fd                                   ..X...
2021-11-10:04:19:54.728949: frame.c(458):read_icom_frame entered
2021-11-10:04:19:54.728952: read_string called, rxmax=80
2021-11-10:04:19:54.746677: read_string(): RX 6 characters
2021-11-10:04:19:54.746715: 0000    fe fe 58 e0 03 fd                                   ..X...
2021-11-10:04:19:54.746719: frame.c(495):read_icom_frame return(6)
2021-11-10:04:19:54.746723: frame.c(458):read_icom_frame entered
2021-11-10:04:19:54.746727: read_string called, rxmax=80
2021-11-10:04:19:54.759592: read_string(): RX 11 characters
2021-11-10:04:19:54.759611: 0000    fe fe e0 58 03 00 40 07 14 00 fd                    ...X..@....
2021-11-10:04:19:54.759615: frame.c(495):read_icom_frame return(11)
2021-11-10:04:19:54.759619: icom_one_transaction: frm_len=11, frm_len-1=fd, frm_len-2=00
2021-11-10:04:19:54.759622: frame.c(386):icom_one_transaction return(0)
2021-11-10:04:19:54.759625: frame.c(438):icom_transaction return(0)
2021-11-10:04:19:54.759629: icom.c(1542) trace
2021-11-10:04:19:54.759633: set_vfo_curr: vfo=None, curr_vfo=None
2021-11-10:04:19:54.759636: set_vfo_curr: curr_vfo now=None
2021-11-10:04:19:54.759639: icom.c(9087):set_vfo_curr return(0)
2021-11-10:04:19:54.759643: from_bcd called
2021-11-10:04:19:54.759646: icom_get_freq exit vfo=None, curr_vfo=currVFO
2021-11-10:04:19:54.759649: icom.c(1634):icom_get_freq return(0)
2021-11-10:04:19:54.759666: rig_get_freq: elapsed=64ms


Mike W9MDB

On Tuesday, November 9, 2021, 05:54:11 PM CST, Dean Souleles <dsouleles@...> wrote:


Hi Bill,

So I *thought* sending NG in response to the undocumented cmd 25 for the IC-746 fixed my issue with WSJTX connecting to my IC-746 emulation but now I am getting a "Rig Failure" message that says "Command rejected by Rig" which it is!   

I can figure out what a reasonable response is a get it working but it seems like neither a GOOD or NG response will satisfy Hamlib.  Not sure how to report an issue to the Hamlib team - I'll have to look around.

73,
Dean
KK4DAs
Heikki Pisilä
 
Edited

Hi Mike, why did you enable DTR when using CAT? You can remove this "HIGH" from the DTR and test again.

73 Heikki/oh8gkp
Dean Souleles
 

On Wed, Nov 10, 2021 at 03:16 AM, Michael Black wrote:
If you send me the debug logs I can probably figure out what you're doing wrong.
Mike - thanks - how do I enable/find the debug log?  I will give it a shot.

Dean
KK4DAS
Dean Souleles
 

Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,
Dean
KK4DAS

?
debug-252.log
?
debug-222.log

Michael Black
 

The 252 log now shows your simulator is not responding to the x03 command....all Icom rigs respond to that one.
The current serial code is faster than the older code so that may be why it's behaving different.
You apparently are either flushing it or somehow ignoring it.
That's how it detects echo on/off.

Mike W9MDB






On Thursday, November 11, 2021, 09:52:47 AM CST, Dean Souleles <dsouleles@...> wrote:


Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,

Dean
KK4DAS



Bill Somerville
 

Mike,

both logs show the emulator does not reply to the initial frequency read CAT command. The 2.5.2 version takes 15 seconds to timeout, which seems excessive, then doesn't retry the command. The 2.2.2 version does a retry after a roughly 1 3/4 second timeout and that retry succeeds. Clearly the way Hamlib handles timeouts and retries has changed for the worse.

73
Bill
G4WJS.

On 11/11/2021 16:09, Michael Black via groups.io wrote:
The 252 log now shows your simulator is not responding to the x03 command....all Icom rigs respond to that one.
The current serial code is faster than the older code so that may be why it's behaving different.
You apparently are either flushing it or somehow ignoring it.
That's how it detects echo on/off.

Mike W9MDB






On Thursday, November 11, 2021, 09:52:47 AM CST, Dean Souleles <dsouleles@...> wrote:


Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,

Dean
KK4DAS


Michael Black
 

Yes...that handling was changed...and this emulator is the only Icom "rig" that has a problem.  I'd rather see the emulator fixed than introduce another timeout loop.  It used to loop around the 0x03 command numerous times which was causing other problems with long timeouts.

Right now it expects the 1st 0x03 command to work and nobody else has found a problem that I know of.

Mike W9MDB



On Thursday, November 11, 2021, 10:13:43 AM CST, Bill Somerville <g4wjs@...> wrote:


Mike,

both logs show the emulator does not reply to the initial frequency read CAT command. The 2.5.2 version takes 15 seconds to timeout, which seems excessive, then doesn't retry the command. The 2.2.2 version does a retry after a roughly 1 3/4 second timeout and that retry succeeds. Clearly the way Hamlib handles timeouts and retries has changed for the worse.

73
Bill
G4WJS.

On 11/11/2021 16:09, Michael Black via groups.io wrote:
The 252 log now shows your simulator is not responding to the x03 command....all Icom rigs respond to that one.
The current serial code is faster than the older code so that may be why it's behaving different.
You apparently are either flushing it or somehow ignoring it.
That's how it detects echo on/off.

Mike W9MDB






On Thursday, November 11, 2021, 09:52:47 AM CST, Dean Souleles <dsouleles@...> wrote:


Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,

Dean
KK4DAS





Bill Somerville
 

Mike,

you have added a CAT transaction to determine if CI-V command echo is happening (btw there is no way that it can't happen with rigs like the IC-746 since the CI-V bus driver is built into the rig,! But aside from that). Your code does not distinguish between no response at all and a valid response without a command echo preceding it. The fault lies firmly with Hamlib as it should not be ploughing on without consideration for a critical initial transaction not working. Why is the transaction not retried? Why is a fatal error not issued to the rig_open() API call when it cannot communicate with the rig satisfactorily?

73
Bill
G4WJS.

On 11/11/2021 16:27, Michael Black via groups.io wrote:
Yes...that handling was changed...and this emulator is the only Icom "rig" that has a problem.  I'd rather see the emulator fixed than introduce another timeout loop.  It used to loop around the 0x03 command numerous times which was causing other problems with long timeouts.

Right now it expects the 1st 0x03 command to work and nobody else has found a problem that I know of.

Mike W9MDB



On Thursday, November 11, 2021, 10:13:43 AM CST, Bill Somerville <g4wjs@...> wrote:


Mike,

both logs show the emulator does not reply to the initial frequency read CAT command. The 2.5.2 version takes 15 seconds to timeout, which seems excessive, then doesn't retry the command. The 2.2.2 version does a retry after a roughly 1 3/4 second timeout and that retry succeeds. Clearly the way Hamlib handles timeouts and retries has changed for the worse.

73
Bill
G4WJS.

On 11/11/2021 16:09, Michael Black via groups.io wrote:
The 252 log now shows your simulator is not responding to the x03 command....all Icom rigs respond to that one.
The current serial code is faster than the older code so that may be why it's behaving different.
You apparently are either flushing it or somehow ignoring it.
That's how it detects echo on/off.

Mike W9MDB






On Thursday, November 11, 2021, 09:52:47 AM CST, Dean Souleles <dsouleles@...> wrote:


Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,

Dean
KK4DAS


Bill Somerville
 

Mike,

further to the comments below, the default of assuming CI-V echo is not happening is just plain wrong. If the default had been the same as the Icom default, which is CI-V echo is on except in the special circumstances where a dual USB and CI-V bus is present, *and* the user has chosen to un-link the two buses, *and* the user has chosen to then disable command echo on the USB CI-V bus emulation. Only then is CI-V echo disabled.

Even with the broken code in the 2.5.2 version that doesn't distinguish between no response and a valid response with no command echo, if the Hamlib code had defaulted to CI-V echo (by far the most common situation, and the Icom default) then the following behaviour would have been much better.

73
Bill
G4WJS.

On 11/11/2021 16:34, Bill Somerville wrote:
Mike,

you have added a CAT transaction to determine if CI-V command echo is happening (btw there is no way that it can't happen with rigs like the IC-746 since the CI-V bus driver is built into the rig,! But aside from that). Your code does not distinguish between no response at all and a valid response without a command echo preceding it. The fault lies firmly with Hamlib as it should not be ploughing on without consideration for a critical initial transaction not working. Why is the transaction not retried? Why is a fatal error not issued to the rig_open() API call when it cannot communicate with the rig satisfactorily?

73
Bill
G4WJS.

On 11/11/2021 16:27, Michael Black via groups.io wrote:
Yes...that handling was changed...and this emulator is the only Icom "rig" that has a problem.  I'd rather see the emulator fixed than introduce another timeout loop.  It used to loop around the 0x03 command numerous times which was causing other problems with long timeouts.

Right now it expects the 1st 0x03 command to work and nobody else has found a problem that I know of.

Mike W9MDB



On Thursday, November 11, 2021, 10:13:43 AM CST, Bill Somerville <g4wjs@...> wrote:


Mike,

both logs show the emulator does not reply to the initial frequency read CAT command. The 2.5.2 version takes 15 seconds to timeout, which seems excessive, then doesn't retry the command. The 2.2.2 version does a retry after a roughly 1 3/4 second timeout and that retry succeeds. Clearly the way Hamlib handles timeouts and retries has changed for the worse.

73
Bill
G4WJS.

On 11/11/2021 16:09, Michael Black via groups.io wrote:
The 252 log now shows your simulator is not responding to the x03 command....all Icom rigs respond to that one.
The current serial code is faster than the older code so that may be why it's behaving different.
You apparently are either flushing it or somehow ignoring it.
That's how it detects echo on/off.

Mike W9MDB






On Thursday, November 11, 2021, 09:52:47 AM CST, Dean Souleles <dsouleles@...> wrote:


Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,

Dean
KK4DAS


Michael Black
 

The error case had never been seen before....looks like I can catch it and do a retry in this case.  Still have to figure out why the 15 seconds....that's too long.

Mike




On Thursday, November 11, 2021, 10:34:21 AM CST, Bill Somerville <g4wjs@...> wrote:


Mike,

you have added a CAT transaction to determine if CI-V command echo is happening (btw there is no way that it can't happen with rigs like the IC-746 since the CI-V bus driver is built into the rig,! But aside from that). Your code does not distinguish between no response at all and a valid response without a command echo preceding it. The fault lies firmly with Hamlib as it should not be ploughing on without consideration for a critical initial transaction not working. Why is the transaction not retried? Why is a fatal error not issued to the rig_open() API call when it cannot communicate with the rig satisfactorily?

73
Bill
G4WJS.

On 11/11/2021 16:27, Michael Black via groups.io wrote:
Yes...that handling was changed...and this emulator is the only Icom "rig" that has a problem.  I'd rather see the emulator fixed than introduce another timeout loop.  It used to loop around the 0x03 command numerous times which was causing other problems with long timeouts.

Right now it expects the 1st 0x03 command to work and nobody else has found a problem that I know of.

Mike W9MDB



On Thursday, November 11, 2021, 10:13:43 AM CST, Bill Somerville <g4wjs@...> wrote:


Mike,

both logs show the emulator does not reply to the initial frequency read CAT command. The 2.5.2 version takes 15 seconds to timeout, which seems excessive, then doesn't retry the command. The 2.2.2 version does a retry after a roughly 1 3/4 second timeout and that retry succeeds. Clearly the way Hamlib handles timeouts and retries has changed for the worse.

73
Bill
G4WJS.

On 11/11/2021 16:09, Michael Black via groups.io wrote:
The 252 log now shows your simulator is not responding to the x03 command....all Icom rigs respond to that one.
The current serial code is faster than the older code so that may be why it's behaving different.
You apparently are either flushing it or somehow ignoring it.
That's how it detects echo on/off.

Mike W9MDB






On Thursday, November 11, 2021, 09:52:47 AM CST, Dean Souleles <dsouleles@...> wrote:


Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,

Dean
KK4DAS





Bill Somerville
 

Mike,

I guess that  15 S delay is related to code to power up the rig from standby, something else that is not possible on an IC-746!

73
Bill
G4WJS.

On 11/11/2021 16:47, Michael Black via groups.io wrote:
The error case had never been seen before....looks like I can catch it and do a retry in this case.  Still have to figure out why the 15 seconds....that's too long.

Mike




On Thursday, November 11, 2021, 10:34:21 AM CST, Bill Somerville <g4wjs@...> wrote:


Mike,

you have added a CAT transaction to determine if CI-V command echo is happening (btw there is no way that it can't happen with rigs like the IC-746 since the CI-V bus driver is built into the rig,! But aside from that). Your code does not distinguish between no response at all and a valid response without a command echo preceding it. The fault lies firmly with Hamlib as it should not be ploughing on without consideration for a critical initial transaction not working. Why is the transaction not retried? Why is a fatal error not issued to the rig_open() API call when it cannot communicate with the rig satisfactorily?

73
Bill
G4WJS.

On 11/11/2021 16:27, Michael Black via groups.io wrote:
Yes...that handling was changed...and this emulator is the only Icom "rig" that has a problem.  I'd rather see the emulator fixed than introduce another timeout loop.  It used to loop around the 0x03 command numerous times which was causing other problems with long timeouts.

Right now it expects the 1st 0x03 command to work and nobody else has found a problem that I know of.

Mike W9MDB



On Thursday, November 11, 2021, 10:13:43 AM CST, Bill Somerville <g4wjs@...> wrote:


Mike,

both logs show the emulator does not reply to the initial frequency read CAT command. The 2.5.2 version takes 15 seconds to timeout, which seems excessive, then doesn't retry the command. The 2.2.2 version does a retry after a roughly 1 3/4 second timeout and that retry succeeds. Clearly the way Hamlib handles timeouts and retries has changed for the worse.

73
Bill
G4WJS.

On 11/11/2021 16:09, Michael Black via groups.io wrote:
The 252 log now shows your simulator is not responding to the x03 command....all Icom rigs respond to that one.
The current serial code is faster than the older code so that may be why it's behaving different.
You apparently are either flushing it or somehow ignoring it.
That's how it detects echo on/off.

Mike W9MDB






On Thursday, November 11, 2021, 09:52:47 AM CST, Dean Souleles <dsouleles@...> wrote:


Hi all - 

Much thanks to Mike, W9MDB who has been very patient in helping me debug, but I have not yet been able to solve my problem.  So I am hoping a hamlib wizard can help me out here since I am not real clear on what hamlib is trying to do here,

Attached are two log files from rigctld-wsjtx - on from version 2.2.2 where my IC-746 emulator works with WSJTX and one from 2.5.2 where my emulator does not work.    In both cases it looks like wsjtx is timing out after its initial send of a command, in the 2.2.2 case it times out after less than 2 seconds, recovers and then starts communicating with the rig.  In the 2.5.2 case the timeout is much longer - 15 seconds - and then the communication protocol never syncs up properly.  I'm not sure why the initial timeout is happening as the rig is sending back the response.  

If any hamlib wizard could take a look and let me know what you think it would be greatly appreciated. I have a small group of users that are using my emulator - and for now I have advised them to roll back to 2.2.2 - while I try to figure this out.  

My test procedure is to configure WSJTC for No rig.
Run rigctld-wsjtx  and redirect the output to a log file
In wsjtx select rig Hamlib NET rigctl and press the Test Cat button

For background I have written an IC-746 emulator which runs on an Arduino as as part of the control program for homebrew QRP rigs.  It works with all PC cat control programs I have tried and was working with WSJTX until some time after version 2.2.2.  For anyone interested the Github is here...

kk4das/IC746CAT: ICOM IC-746 Computer Aided Transceiver (CAT) control emulation for Arduino (github.com)

Thanks again to the community!

73,

Dean
KK4DAS


Dean Souleles
 

Thank you fellas! 

I realize my little emulator project is not a high priority in hamlib or WSJTX land and would be happy to adjust the code as needed.  And I do appreciate your attention.  I have confirmed that the rig receives and responds to the initial 0x03 command. I can't account for why hamlib times out on that initial call.

73,
Dean
KK4DAS
Dean Souleles
 

On Thu, Nov 11, 2021 at 11:47 AM, Michael Black wrote:
The error case had never been seen before....looks like I can catch it and do a retry in this case.  Still have to figure out why the 15 seconds....that's too long.
Hi Mike -

Does it look like this is something you will be able address?  I'm still not sure why the initial transaction is timing out - it may be timing due to the fact that the Arduino resets on the PC asserting with DTR High.  That said a retry would definitely helpful

Thanks,
Dean
KK4DAS
Dean Souleles
 

On Thu, Nov 11, 2021 at 11:47 AM, Michael Black wrote:
The error case had never been seen before....looks like I can catch it and do a retry in this case.  Still have to figure out why the 15 seconds....that's too long.
 
HI Mike - 

Trying not to be a nag - do you think this can be addressed in an upcoming release?  I fully understand - you don't want put in a fix for my knock-off emulator and risk breaking actual commercial rigs.  I've got about 15 guys who have built transceivers using the emulator - for now I am advising them to use the FlRIG interface which works fine business.

I can't account for why the Arduino misses the first command from wsjtx/hamlib.  I suspect something odd in the serial handshake between the Arduino and the PC.   I believe but haven't confirmed that other CAT programs are working ok since they retry - particularly during startup.  The old freeware version of HRD exhibits a slight pause between when you hit "connect" and when the radio control UI launches, but it connects 100% of the time.

73 and thanks again for all you do,

Dean
KK4DAS
Michael Black
 

I already put the retry in.  Is it still not working with the current master?

Mike W9MDB




On Sunday, November 21, 2021, 02:48:45 PM CST, Dean Souleles <dsouleles@...> wrote:


On Thu, Nov 11, 2021 at 11:47 AM, Michael Black wrote:
The error case had never been seen before....looks like I can catch it and do a retry in this case.  Still have to figure out why the 15 seconds....that's too long.
 
HI Mike - 

Trying not to be a nag - do you think this can be addressed in an upcoming release?  I fully understand - you don't want put in a fix for my knock-off emulator and risk breaking actual commercial rigs.  I've got about 15 guys who have built transceivers using the emulator - for now I am advising them to use the FlRIG interface which works fine business.

I can't account for why the Arduino misses the first command from wsjtx/hamlib.  I suspect something odd in the serial handshake between the Arduino and the PC.   I believe but haven't confirmed that other CAT programs are working ok since they retry - particularly during startup.  The old freeware version of HRD exhibits a slight pause between when you hit "connect" and when the radio control UI launches, but it connects 100% of the time.

73 and thanks again for all you do,


Dean
KK4DAS
1 - 20 of 27