[K3][TQ; ] would it be possible to return the reason we are in tx mode?

[AG2F]

Hi folks,

As I understand it, when the K3 receives the GET command `TQ:' it will respond with `TQ1;', even if the K3 has been placed in |TX TEST|.  It would be useful for us programmer types if this query were followed by an argument that qualified what manner of transmit mode the K3 was in; e.g., `TQ1,TEST;'. Of course the argument could return a single character which encoded the qualification, but my example expresses the type of information that would be useful, without suggesting the syntax.

Best wishes,

--
Kyle Smith (AG2F)
K3 #NEW, P3# NEW, and many other Elecraft products for which I have no memory of their serial number. Someday, when I have nothing to do, I'll put them all in a spreadsheet.
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Dick Dievendorff]

You can determine the TxTest state from the IC command response.  This is
the technique used in the K3 Utility.

73 de Dick, K6KR


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Kyle Smith
Sent: Friday, May 27, 2011 6:50 AM
To: [hidden email]
Subject: [Elecraft] [K3][TQ; ] would it be possible to return the reason we
are in tx mode?

Hi folks,

As I understand it, when the K3 receives the GET command `TQ:' it will
respond with `TQ1;', even if the K3 has been placed in |TX TEST|.  It would
be useful for us programmer types if this query were followed by an argument
that qualified what manner of transmit mode the K3 was in; e.g.,
`TQ1,TEST;'. Of course the argument could return a single character which
encoded the qualification, but my example expresses the type of information
that would be useful, without suggesting the syntax.

Best wishes,

--
Kyle Smith (AG2F)
K3 #NEW, P3# NEW, and many other Elecraft products for which I have no
memory of their serial number. Someday, when I have nothing to do, I'll put
them all in a spreadsheet.
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[AG2F]

Thanks Dick,

I suppose a program should be receiving `IC' state information rather frequently, to maintain synchronicity with the myriad state registers that are maintained and exposed by the K3's API.  My hope was that the `TQ;' directive would be able to inform the programmer of the event by which the K3 had put itself into the `TQ1;' state. Perhaps this historical data simply isn't available, but, for instance, it would be of great value to know if the rear panel PTT had been asserted, or the user had manually pushed the front panel TX button, or the front panel Mic Jack had asserted PTT, or VOX was activated, or either the RST or DTR of the serial port had been asserted, or the K3 had received a CAT command that resulted in the K3 responding with `TQ1;'.  It is of such great value, because of the high probability that two or more applications, and/or the various sound card interfaces, will be configured in ways which are incompatible with respect to controlling the transmit state of t
 he K3.  An application that took advantage of this causal data would be very helpful in aiding the operator with the setup of new software or hardware that interfaced with the K3.  I am not yet fluent in the API for the K3, but I have experienced anomalies with various applications, all claiming compatability with the K3, but they don't play well with others, perhaps because this information is simply not available to applications, which then prevents them from self configuration, and leads to race conditions, culminating in the K3 being seemingly stuck in transmit mode.  As more and more, operators will be taking advantage of remote control of their SDR radios, it becomes impairitive that applications take on the responsibility of coordinating their control over the K3, such that the remote operator can have the necessary final and deterministic control over the tx status of their rig(s).  That's the way I see it, at least. Maybe others have a different perspective.  It wou
 ld be interesting to hear from the members on this reflector on the subject.

Best wishes,

--
Kyle Smith (AG2F)
[hidden email]

On May 27, 2011, at 10:36 AM, Dick Dievendorff <[hidden email]> wrote:

> You can determine the TxTest state from the IC command response.  This is
> the technique used in the K3 Utility.
>
> 73 de Dick, K6KN
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html