As you noted offline, Bill, I did not receive the message below. My comments
are preceded by +++.
On 01/07/2017 13:49, Bill Somerville wrote:
>
> 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?
+++ If the Commander is configured to control a transceiver that supports RX/TX
switching via an external signal, Commander keeps
track of the transceiver's RX/TX state, and report that.
+++ If Commander can't control the transceiver's RX/TX state either via an
external signal or via a CAT command, and if the
transceiver can't report its RX/TX state via a CAT command, then the CmdSendTX
command above will always report <CmdTX:2>ON
> 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.
+++ As you report below, Commander already does that.
To complement the opposite
> would be needed for directives to return to receive.
+++ As you report below, Commander already does that.aa
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?
+++ That's purely a "consumption of CPU resources" issue.
We would like to be able to detect the rig PTT
> event within 100ms at worst.
+++ Polling every 100 ms should have no measurable impact on CPU resource
consumption.
> 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?
+++ Yes. It also works if a parallel port data signal is used to switch the
transceiver between RX and TX.
>
> 73
> Bill
> G4WJS.
>
Hi Dave,
as a further data point. I am experimenting with the Commander TCP/IP
command CmdSendTX and I am seeing an interesting behaviour. Just using
the command after sending a CmdTX command seems to synchronize with the
actual rig PTT event. I assume this is because CmdSendTX is queued in
Commander behind the CmdTX command and the reply cannot be delivered
until the former has been actioned.
+++ Correct.
This is despite the rig I am using
having no CAT command to query PTT (IC-756) so it also appears to answer
my query above about what happens in that case.
+++ Correct. Presumably, you're using an external interface controlled by a
serial port modem control signal or parallel port data
signal to generate a SEND signal for your IC-756.
I will code a change to WSJT-X than does multiple CmdSendTX commands at
10ms intervals until the expected response occurs or 1s expires. If one
second expires WSJT-X will abort with a suitable error on the basis that
the rig is not working.
+++ There may be some older transceivers that report RX/TX status via CAT
command but could take longer than 1 second to switch
state after being directed to do so. Ideally, you would poll every 10 ms for 1
second, and then poll every 100 ms for another 2
seconds before concluding that there's a problem.
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
