>>>AA6YQ comments below
-----Original Message-----
From: Bill Somerville [mailto:[email protected]]
Sent: Friday, June 30, 2017 9:31 PM
To: [email protected]
Subject: Re: [wsjt-devel] WSJT-X: Important, [please read if you use an
external PA with WSJT-X
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.
>>>Commander could be readily extended to send a message each time a command is
>>>issued to the transceiver. No application can reliably inform you when a
>>>command sent to a transceiver has been fully processed by that transceiver,
>>>because no transceiver makes that information available. One can know that
>>>some aspect of a command has been executed -- for example, the transceiver's
>>>reported state has changed from RX to TX -- but that doesn't mean that the
>>>"transmit" command has been fully processed; for example, there's no
>>>guarantee that RF is yet being emitted.
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.
>>>You have the ability to monitor a transceiver's RX/TX state -- as reported
>>>by the transceiver. Only Icom, TenTec, and some old Yaesu radios provide
>>>explicit "command accepted" responses, but a "command accepted" response
>>>does not necessarily mean "command successfully executed".
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
>>>There are several transceivers that cannot accept state-setting commands
>>>without pacing. The FT-450, for example. The Elecraft K3 requires a 500 ms
>>>delay after a band change, to cite another example.
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).
>>>Kenwood, Elecraft, and recent Yeasu transceivers do not provide ACK
>>>responses. As pointed out above, the ACK responses from Icom transceivers
>>>mean "command accepted", not "command processed"; Icom transceivers send an
>>>ACK to indicate that a command was received without a CI-V bus collision,
>>>and thus need not be re-sent.
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.
>>>You can setup a thread that busy-waits for the CmdSendTX command to report
>>>"transmitting", or we can consider adding a second TCP port to which you can
>>>connect to receive notifications of events to which you have subscribed,
>>>e.g. "transmitting".
73,
Dave, AA6YQ
------------------------------------------------------------------------------
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
