locked Re: Disable TX After 73


I just did another test to change TX4 from RR73 to RRR and find in that case, the TX will remain enabled and stick on TX4 until receiving the final "73" as TX5 from the remote.  After receiving that 73, the autosequencer will inhibit TX and drop down to TX6.

If TX4 is "RR73", then the autosequencer immediately disables TX and messaging drops down to TX6 without waiting for the remote to send his TX5.  This action is independent of the "Disable TX after sending 73" setting.

So, the way the "Disable after sending 73" logic works for ft8, and presumably for ft4, in V2.2.1 is dependent on the text contained in TX4 and the "Disable ..." setting.  If you want the autosequencer to hold off inhibiting TX until receiving TX5 from the remote, then set TX4 to <remotecall><mycall>RRR.  If you don't want to wait for that final 73 from the remote, set TX4 to <remotecall><mycall>RR73.

It's too bad the logic is set up to detect the "73" string instead of just whether TX4 is being sent, as I've pointed out in a similar parallel thread on this forum.  This way, I can't send my 73 and hold off the TX inhibit to wait for the return 73 - I (and the remote) will have to be satisfied with an RRR.

With respect to comments that the developers didn't want to make wsjtx more robotic, I understand and support that concept.  However, the autosequencer is rather robotic in that it automates the TX messaging all the way; it only stops after reaching TX 4 or 5 depending on the CQ origination - something akin to the difference between full and semi-auto.   The issue being discussed in this thread is to gain a better understand of exactly how the autosequencer behaves when reaching TX4.  Hopefully the above discussion provides clarification, even though it's a tad unfortunate that it's dependence is on the text of TX4, but that's just my opinion.

Hugo, ve3ktn.

Join main@WSJTX.groups.io to automatically receive all group messages.