locked Disable TX After 73


Ken Arck AH6LE
 

Version 2.1.2, Win10 64 Bit Home Edition

I have that unchecked but ENABLE TX is no longer highlighted after sending 73.

Bug? Operator error?

Ken
------------------------------------------------------------------------------
President and CTO - Arcom Controllers
Makers of repeater controllers and accessories.
https://www.arcomcontrollers.com/
Authorized Dealers for Kenwood and Telewave.
We we offer complete turn-key repeater packages!
AH6LE/R - IRLP Node 3000
http://www.irlp.net
"We don't just make 'em. We use 'em!"
[]


Marlo Montanaro - KA2IRQ
 

I'm with ya... Unless I'm missing something, I have not seen where that check box does anything.

73,
Marlo
KA2IRQ


Tom Melvin
 

I seem to remember something for years back - this option was never meant to work on FT4/FT8 it was aimed at one of the other modes MSK?   Memory is not that good but the use of it comes up periodically and results in the same discussion.  

Tom

--
73

Tom
GM8MJV (IO85)





On 20 Jun 2020, at 15:15, Marlo Montanaro - KA2IRQ <ka2irq@...> wrote:

I'm with ya... Unless I'm missing something, I have not seen where that check box does anything.

73,
Marlo
KA2IRQ




Bob G8HGN
 

Hi,

Yes it did work in the early versions, on all modes. But it was felt that robotic QSOs would result if used on FT8/4, so it was withdrawn for those modes.

I believe it still works for the others?

73

Bob G8HGN


On 20/06/2020 22:18, Tom Melvin wrote:
I seem to remember something for years back - this option was never meant to work on FT4/FT8 it was aimed at one of the other modes MSK?   Memory is not that good but the use of it comes up periodically and results in the same discussion.  

Tom

--
73

Tom
GM8MJV (IO85)





On 20 Jun 2020, at 15:15, Marlo Montanaro - KA2IRQ <ka2irq@...> wrote:

I'm with ya... Unless I'm missing something, I have not seen where that check box does anything.

73,
Marlo
KA2IRQ





    


Frode Igland
 

Bob G8HGN has an excellent memory. I copy an e-mail from Bill G4WJS dated 21 June 2018, settling the case:
auto-tx after sending a 73 message is disabled when you have "Call 1st" 
checked, this is a deliberate choice by the developers to stop WSJT-X 
becoming a automatic "QSO machine".

73
Bill
G4WJS.
This means the checking "Disable TX after 73, will disable TX, whilst NOT checking it will NOT "Enable TX" after 73. The asymmetry is intended and very well justified.
The developers will not allow a QSO robot, which, for FT4 and FT8, would be the only purpose of allowing automatic "Enable TX".

For other modes, like MSK144, where completing a contact often requires many attempts and repeats to receive your QSO partner's confirmation, keeping the TX enabled has a purpose.

So, for FT4 and FT8 just forget the "Disable TX after 73" check box. Serious rule-abiding radio amateurs should not look for QSO robots. 73 Frode LA6VQ


VE3KTN
 

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.



Reino Talarmo
 

>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.
Hugo, ve3ktn.
Hi Hugo,
Perhaps knowing how RR73 came into the autosequence would help to understand why Tx 4 seems to behave ‘wrongly’. Originally R+nn report were confirmed by RRR and a 73 was sent later to indicate ‘I am happy now and have logged QSO’. At some stage it was noted that locator RR73 can be sent in the Tx 4 message and that is a combination of RRR and 73 in a single message. The meaning was taken from message Tx 5 i.e. it is the final message from me, tnx.
73, Reino OH3mA


VE3KTN
 

Hello Reino, and thanks for the background.  I just had to tear myself away from this crazy North America 6m opening this afternoon - my fingers are getting tired  :-P.

Oh boy.  I thought my last post describing in detail what I see would be the last, but .....

Observing again and more closely what happens after sending CQ and letting the autosequencer go, if I set TX4 to "RRR", then it waits for the remote response of "73" without disabling TX.  If it receives that 73, my rig will transmit back a TX5 and at the same time the TX Enable goes white (i.e. indicating that it is disabled even though TX5 is in progress), then drops to TX6 and is ready for the next QSO.  All of this independent of the "Disable TX after sending 73" setting.  It seems a bit redundant to send both the TX4 and TX5, but that's the way it is and the CQ originator has to wait another 15 seconds to send his TX5 (unless he forces a TX Halt).

All of this would seem to support my point that there must be a better way to end the autosequence than trapping on "73".  Maybe in V3.0.0 ?  ;-)

Oh, and BTW, auto launching of the Log QSO window is independent of the message selected for TX4.  It will pop up after TX4 if set to "RR73" and after TX5 if TX4 is set to "RRR" and TX5 is the default "73" message.

I'm almost afraid to set TX4 to "RRR" and TX5 to a free text not containing "73".

73,
Hugo, ve3ktn.


Frode Igland
 

From: VE3KTN
Date: Sun, 21 Jun 2020 09:21:10 PDT

...
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.

...

Hugo,

All it takes to keep everything smooth is to check the "Enable TX" button as soon as you send the RR73 (and "Enable TX" is disabled). If your QSO partner returns with R+report, RR73 will automatically be sent again, because obviously he/she did not copy your first RR73, and still don't know if you received his/her report. If your QSO partner returns with 73, he/she received everything, and your next CQ is sent. No sequence is lost, and the operation is very efficient. Having to click "Enable TX"  is just enough 1. to avoid robot automation, 2. to keep us busy, and 3. to keep our attention on what is going on with our radios, which of course is where we should keep our attention.

73 Frode LA6VQ




Hasan Schiers N0AN
 

Fried, I do the same thing just click Enable TX near the end of your last transmission and it will either call CQ or repeat RR73, whichever is required!

Any further automation is a slippery slope to autobot ops. 

This is fast enough to work short lived sporadic E openings efficiently,  especially if you double click on TX1 so you start qsos with TX2, saving 15 seconds.

73, N0AN 

Hasan


On Sun, Jun 21, 2020, 5:25 PM Frode Igland <frodeigland2@...> wrote:
From: VE3KTN
Date: Sun, 21 Jun 2020 09:21:10 PDT

...
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.

...

Hugo,

All it takes to keep everything smooth is to check the "Enable TX" button as soon as you send the RR73 (and "Enable TX" is disabled). If your QSO partner returns with R+report, RR73 will automatically be sent again, because obviously he/she did not copy your first RR73, and still don't know if you received his/her report. If your QSO partner returns with 73, he/she received everything, and your next CQ is sent. No sequence is lost, and the operation is very efficient. Having to click "Enable TX"  is just enough 1. to avoid robot automation, 2. to keep us busy, and 3. to keep our attention on what is going on with our radios, which of course is where we should keep our attention.

73 Frode LA6VQ





 

I was about to report it as a bug, but decided to do a quick search. OK understand, and I do re-enable TX most times after I send RR73, especially as that also resends RR73 if your QSO partner repeats the Rxx message. I's just I sometimes forget and then it's a nuisance.

Maybe the settings button for this should be disabled if "Call 1st" is set.
--
73 Phil GM3ZZA