Re: #Cat_RigControl #Cat_RigControl

Bill Somerville


CAT responses should be within milliseconds, if your software is taking over 1 second to respond to a CAT command then it is not suitable for use with WSJT-X.


On 29/04/2021 19:49, Bob Stricklin wrote:
Hi Bill,

The issue I am seeing is timeouts on commands that take longer than WSJTX allows.

While working with a Hamlib CMD I for instance I captured the following using the WSJTX loging feature…..

[2021-04-28 02:42:47.983260][00:00:30.484853][RIGCTRL:trace] 0000    49 20 31 34 34 31 37 34 30 30 30 2e 30 30 30 30     I 144174000.0000
[2021-04-28 02:42:47.983276][00:00:30.484869][RIGCTRL:trace] 0010    30 30 0a                                            00.
[2021-04-28 02:42:47.983292][00:00:30.484884][RIGCTRL:trace] read_string called, rxmax=96
[2021-04-28 02:42:48.984465][00:00:31.486061][RIGCTRL:warning] read_string(): Timed out 1.001 seconds after 0 chars
[2021-04-28 02:42:48.984550][00:00:31.486143][RIGCTRL:debug] rig.c(3382):rig_set_split_freq return(-5)
[2021-04-28 02:42:48.984588][00:00:31.486181][RIGCTRL:debug] rig.c(3899):rig_set_split_freq_mode return(-5)
[2021-04-28 02:42:48.984604][00:00:31.486197][RIGCTRL:error] error: Communication timed out

WSJTX indicates it is timing out before my code and Hamlib get back with a reply. I reduced the amount of code I had active in the CMD I instruction and the the time issue goes away.

This is what led to my comment. I feel the timing requirements of a command like this are not critical. I know there has to be a time limit of some sort in WSJTX to cover the non responsive commands issued but this limit should be extended to give more latitude to user. How much time is needed, maybe 3 to 5 seconds. My code is on the edge now so if the timeout doubled it would help.

The error message seems like a generic error message which may be sent for more than one reason, this is just my observation and not a problem.

I am working here to get everything done within the time limits needed by WSJTX. It would help me though and possible others if the timing needs were relaxed a bit on non critical commands. I wanted to get the comment out there before the evaluation of the current version completed.

Thanks for all your efforts in making WSJTX a great package and helping the community. We are lucky to have your support!


On Apr 28, 2021, at 7:48 AM, Bill Somerville <g4wjs@...> wrote:

On 28/04/2021 10:18, Bob Stricklin wrote:
I suggest some relaxation in response timing requirements in Hamlib commands which are not time critical.  All the commands dealing with setting up the radio and feeling out the capabilities do not need to respond in a time critical way. When WSJTX is using combination commands to change frequency, mode and bandwidth you are not time critical.

When working a QSO I can see the need for quick response. The commands like PTT on and off, (T,t) and frequency changes (F,f,I,i) need to be fast as possible. Most of the other commands are not time critical.

The Hamlib command set has to keep up with changes made by the user as well as changes made by the WSJTX package, a second user, to keep the radio on track. There can be a lot of data flowing back and forth.



Hamlib is a synchronous with respect to CAT commands exchanged with the rig, there are no time critical parts for almost all rigs, a couple do need some command pacing but that is rare and not needed on newer models. In summary, Hamlib issues a command and waits for the rig to respond before sending another command. What problem are you reporting, there is no conflict with operating the rig directly and using Hamlib to control and monitor the rig, other than explicit conflicts where the user wants to do one thing and the CAT control program another, that is down to the user to coordinate (or desist) rather than any software requirement.


Join to automatically receive all group messages.