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…..
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
02:42:47.983276][00:00:30.484869][RIGCTRL:trace] 0010 30
30 0a 00.
read_string(): Timed out 1.001 seconds after 0 chars
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
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
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
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.