On 01/07/2017 06:00, Dave AA6YQ wrote:
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".
Hi Dave,
thanks for your comments. I will address the last as that seems to be
the area where I think some progress on safety can be made. The last
version of the Commander TCP/IP documentation you sent us states:
++++++++++++++++++++
16. Report transmit status, e.g.
<command:9>CmdSendTX<parameters:0>
returns a single field in ADIF syntax specifying whether the transceiver
is transmitting, e.g.
<CmdTX:3>OFF
or
<CmdTX:2>ON
Not all transceivers respond to this directive.
---------------------------------
The last sentence is ambiguous. What happens if a transceiver does not
respond?
Could this exchange be modified to deal with the above scenario by
responding with OFF until directive has been sent to the rig to ask it
to transmit when it would return ON. To complement the opposite would be
needed for directives to return to receive. I ask this because at least
we could get into the ballpark of when the rig actually goes to Tx when
a sequence of directives to Commander ending with transmit request are
processed.
WSJT-X already has a dedicated thread for rig control and it can
trivially poll using this command once a request to go to Tx has been
sent, it has nothing else to do at this point. How often is acceptable
for a polling rate? We would like to be able to detect the rig PTT event
within 100ms at worst.
Does the above directive respond with ON if RTS or DTR are used to key
the rig when the rig is one that does not have the ability to report Tx
status via a CAT query?
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
