Sam,
you have not understood my comments and the reason for the dummy
command, please read my explanation again.
73
Bill
G4WJS.
On 16/11/2021 15:00, Sam W2JDB via wsjt-devel wrote:
Hi Bill,
Any invalid command will result in a '?;' response, even a SET command.
i.e. if you send 'AC000' and the tuner is already in a 'AC000' state
in reply
to 'AC;' command, you will get a '?;' response. I used that example
because
I ran into that problem and it took me a while to figure why/where
that was
coming from.
73,
Sam W2JDB
-----Original Message-----
From: Bill Somerville via wsjt-devel <wsjt-devel@lists.sourceforge.net>
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville <g4...@classdesign.com>
Sent: Tue, Nov 16, 2021 9:26 am
Subject: Re: [wsjt-devel] VFOs reversing
On 16/11/2021 14:07, Sam W2JDB via wsjt-devel wrote:
> I also wondering about the multiple
> 'ID' requests, is that your version of heartbeat ? Just wondering.
Hi Sam,
the Kenwood protocol does not respond to CAT commands that set things,
so there is a problem with reading any invalid response ('?') since we
have no way of knowing how long to wait for a response which may never
come. Hamlib gets around this ambiguity with a simple device, after CAT
commands that do not elicit a reply when they work, a basic command that
does elicit a reply is sent. Then we can read a reply and either get the
command failed reply (and discard the expected reply), or the expected
reply from the second command. This simple technique means that CAT
commands can proceed without any wait time, despite extra traffic being
sent.
Other CAT protocols are more robust and always send either an ACK or
NACK response to all commands, so with them there is no ambiguity.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
