HI Dave,
comments in line below.
On 01/07/2017 01:50, Dave AA6YQ wrote:
AA6YQ comments below
-----Original Message-----
From: Bill Somerville [mailto:[email protected]]
Sent: Friday, June 30, 2017 8:33 PM
To: WSJT software development
Subject: [wsjt-devel] WSJT-X: Important, [please read if you use an external PA
with WSJT-X
snip<
There is a notable exception to this in that DX Lab Suite Commander
does not give us a way of knowing when CAT commands have actually been
completed.
You've never asked for this capability, Bill.
This combined with the way that Commander spaces CAT
commands, rather than being paced by the rig's CAT responses, means
that delays of more than 1 second are likely.
I have asked for a way of knowing when commands have been processed a
couple of times. I was led to believe it was not practical for Commander
to deliver that information. For this particular case what is really
needed is a way of knowing when a sequence of TCP/IP commands ending
with a Tx directive have been actioned. By actioned I mean that if RTS
or DTR or some other hard wired PTT is employed then it has been
asserted or if a CAT PTT command is used then the rig has responded that
it has accepted that command.
That could be boiled down to a simple TCP/IP poll of the PTT state so
long as it reflected the above.
The word "pacing" implies a steady and consistent speed, which is exactly what
Commander provides. Commander users can specify
the rate at which CAT commands are executed, thereby establishing an
appropriate balance between responsiveness and CPU consumption.
I understand that is the way you have chosen to implement CAT and it is
not unreasonable but every other implementation seems to use the rig's
responses to determine if a command has been completed and that also
limits resource usage but lets the rig itself pace the progress.
Obviously, either way, state that need to be read from the rig may be
polled at some regular interval but for example OmniRig manages to do
that at a very high rate without CPU load issues. Regardless of polling
for state, here we are talking about state setting commands which IMHO
need no pacing and it is safe to assume that an ACK response from the
rig is sufficient to proceed to the next (the Kenwood style protocol
does complicate that a little due to the absence of an ACK response but
that can be worked around if required).
Bottom line is that even if we can get a confirmation of PTT set after a
few other commands, taking a second or more to complete the commands is
problematic with data mode protocols that need fit into a 15s period,
completion transmitter and audio sequencing, a 13s data transmission,
time to decode and some thinking time for the operator to decide the
next response. The only current safe way to do this with Commander with
some rigs is to add a delay of 1 one more seconds (1.3s in my case with
an IC-756) after sending commands to Commander and before generating any
audio. Not leaving that delay would probably break my recently repaired
PA and and violate my 400W maximum licensed power by a factor of 3 at
the beginning of every transmission.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
