locked #FT8 CQing Refuses to Send 73 After Receiving 73 #FT8


David AD4TJ
 



No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ


David AD4TJ
 





   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.


This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ


David AD4TJ
 



Sorry if you see this multiple times; I have not seen it once in my inbox.

   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ


Bill Somerville
 

On 23/03/2021 11:57, David AD4TJ via groups.io wrote:

No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ

David,

what is the purpose of the extra 73 message you wish top send?

73
Bill
G4WJS.


Larry Banks
 

Hi David,
 
There is no reason to send the second “73” as you have already sent your “RRR” signifying that you acknowledge the QSO.  Therefore the system doesn’t send it.

73 -- Larry -- W1DYJ

 

Sent: Tuesday, March 23, 2021 9:06
Subject: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73
 
 
 
 
 
   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.
 
 
This is v2.4.0-rc3.
 
No one else is seeing this?
 
David AD4TJ






bill.neuro
 

I believe this is how it is supposed to work. You send RRR, he sends 73; QSO done! That's how it works for me.

Bill K1NS


Sent from my T-Mobile 5G Device



Sent from my T-Mobile 5G Device


-------- Original message --------
From: "David AD4TJ via groups.io" <ad4tj@...>
Date: 3/23/21 9:36 AM (GMT-05:00)
To: "WSTJ-X Groups.IO" <wsjtx@groups.io>
Subject: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73



Sorry if you see this multiple times; I have not seen it once in my inbox.

   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ


Carlos
 

Larry and David,
You can also change the RRR to RR73.
So did I !
73, Karl OE3JAG
Am 23.03.21, 15:17 schrieb "Larry Banks via groups.io" <larryb.w1dyj@...>:

Hi David,
 
There is no reason to send the second “73” as you have already sent your “RRR” signifying that you acknowledge the QSO.  Therefore the system doesn’t send it.

73 -- Larry -- W1DYJ

 
Sent: Tuesday, March 23, 2021 9:06
Subject: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73
 
 
 
 
 
   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.
 
 
This is v2.4.0-rc3.
 
No one else is seeing this?
 
David AD4TJ






Larry Banks
 

Correct, and if you use “RR73” you shouldn’t expect a “73” at all.  But then, “RR73” should only be used with good propagation.  From the manual:
 
Similarly, double-click the Tx4 control to toggle between sending RRR and RR73 in that message. The RR73 message should be used only if you are reasonably confident that no repetitions will be required.
 
...although most hams still send the “final 73.”
 
Larry / W1DYJ
 
 
 

From: Carlos
Sent: Tuesday, March 23, 2021 10:53
Subject: Re: Re: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73
 
Larry and David,
You can also change the RRR to RR73.
So did I !
73, Karl OE3JAG
Am 23.03.21, 15:17 schrieb "Larry Banks via groups.io" <larryb.w1dyj@...>:
Hi David,
There is no reason to send the second “73” as you have already sent your “RRR” signifying that you acknowledge the QSO.  Therefore the system doesn’t send it.

73 -- Larry -- W1DYJ

Sent: Tuesday, March 23, 2021 9:06
Subject: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73
   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.
This is v2.4.0-rc3.
No one else is seeing this?
David AD4TJ









Bob G8HGN
 

HI,

Maybe something has changed in the newer versions, as I've just had a QSO using RRR and got 73 from the other op' and sent a 73, all using Auto. As far as I'm aware this has always been the case. See attached screengrab.

The second 73 may be superflous, but it's sent by the program unless prevented by the op' manually.

73 Bob G8HGN


On 23/03/2021 15:02, Larry Banks via groups.io wrote:
Correct, and if you use “RR73” you shouldn’t expect a “73” at all.  But then, “RR73” should only be used with good propagation.  From the manual:
 
Similarly, double-click the Tx4 control to toggle between sending RRR and RR73 in that message. The RR73 message should be used only if you are reasonably confident that no repetitions will be required.
 
...although most hams still send the “final 73.”
 
Larry / W1DYJ
 
 
 
From: Carlos
Sent: Tuesday, March 23, 2021 10:53
Subject: Re: Re: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73
 
Larry and David,
You can also change the RRR to RR73.
So did I !
73, Karl OE3JAG
Am 23.03.21, 15:17 schrieb "Larry Banks via groups.io" <larryb.w1dyj@...>:
Hi David,
There is no reason to send the second “73” as you have already sent your “RRR” signifying that you acknowledge the QSO.  Therefore the system doesn’t send it.

73 -- Larry -- W1DYJ

Sent: Tuesday, March 23, 2021 9:06
Subject: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73
   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.
This is v2.4.0-rc3.
No one else is seeing this?
David AD4TJ












neil_zampella
 

Um ... no ... if you send an RR73, you're done, the RRR is usually used when the conditions are bad, and you want to be sure that both sides of the QSO have confirmed the receipt of the data.

This is covered in the User Manual.

Neil, KN3ILZ

On 3/23/2021 9:31 AM, bill.neuro wrote:
I believe this is how it is supposed to work. You send RRR, he sends 73; QSO done! That's how it works for me.

Bill K1NS


Sent from my T-Mobile 5G Device



Sent from my T-Mobile 5G Device


-------- Original message --------
From: "David AD4TJ via groups.io" <ad4tj@...>
Date: 3/23/21 9:36 AM (GMT-05:00)
To: "WSTJ-X Groups.IO" <wsjtx@groups.io>
Subject: [WSJTX] #FT8 CQing Refuses to Send 73 After Receiving 73



Sorry if you see this multiple times; I have not seen it once in my inbox.

   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ




David AD4TJ
 

The main thing I was trying to say is, it seems as if this is a new behavior; I don't remember ever not having me (my software) not sending a 73 after receiving a 73.

  And the RR73 deal; unless signals are very strong, I don't like to use it, as there are many times that I've sent that and the other guy is still sending AD4TJ xxxxxx RRR; he has not received my RR73.

  On another note, I rarely use FT4; it's aggravating to think the QSO is over but the other guy is still sending RRR; so in the overall scheme of things, I'm not really saving time, as messages have to be repeated to complete. Even signals as strong as single digits below 0 have to be repeated to complete.

David AD4TJ

On Tuesday, March 23, 2021, 9:38:54 AM EDT, Bill Somerville <g4wjs@...> wrote:


On 23/03/2021 11:57, David AD4TJ via groups.io wrote:

No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ

David,

what is the purpose of the extra 73 message you wish top send?

73
Bill
G4WJS.





bill.neuro
 

David

Have you ever operated on CW QSOing a rare station, a contest or a DXpedition. The exchange is

    DX station: QRZ
    ME: K1NS
    DX: K1NS 5NN
    ME: R 5NN
    DX: TU QRZ

Note that I never send his call sign, he usually sometimes sends his call every several QRZs, and usually a TU instead of a 73.

I think the wsjt modes are just following contemporary standards. Quick and minimal.

Bill K1NS


Sent from my T-Mobile 5G Device


-------- Original message --------
From: "David AD4TJ via groups.io" <ad4tj@...>
Date: 3/23/21 2:52 PM (GMT-05:00)
To: main@wsjtx.groups.io, "WSTJ-X Groups.IO" <wsjtx@groups.io>, main@WSJTX.groups.io
Subject: [WSJTX] re: #FT8 CQing Refuses to Send 73 After Receiving 73

The main thing I was trying to say is, it seems as if this is a new behavior; I don't remember ever not having me (my software) not sending a 73 after receiving a 73.

  And the RR73 deal; unless signals are very strong, I don't like to use it, as there are many times that I've sent that and the other guy is still sending AD4TJ xxxxxx RRR; he has not received my RR73.

  On another note, I rarely use FT4; it's aggravating to think the QSO is over but the other guy is still sending RRR; so in the overall scheme of things, I'm not really saving time, as messages have to be repeated to complete. Even signals as strong as single digits below 0 have to be repeated to complete.

David AD4TJ

On Tuesday, March 23, 2021, 9:38:54 AM EDT, Bill Somerville <g4wjs@...> wrote:


On 23/03/2021 11:57, David AD4TJ via groups.io wrote:

No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX.

This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ

David,

what is the purpose of the extra 73 message you wish top send?

73
Bill
G4WJS.





Jim Forsyth
 

Replace your RRR with RR73 and everything will be fine.

Jim, AF6O

On 3/23/2021 6:06 AM, David AD4TJ via groups.io wrote:




   No one has replied to my situation, where I am calling CQ in FT8, someone replies, I send xxxxxxx AD4TJ -19, I receive AD4TJ xxxxxxx R-10, I send xxxxxxx AD4TJ RRR, I receive AD4TJ xxxxxxx 73; now the software should send xxxxxxx AD4TJ 73, but instead it just quits; it prompts me to log the Q, but doesn't send the final 73.  RR73 is not selected. I do have Disable Tx after sending 73 checked, but the 73 is not sent. It is disabling TX BEFORE the 73 is sent. I have to quickly select TX5 and click on Enable TX. Only happens when I call CQ; replying to others CQing is not a problem.


This is v2.4.0-rc3.

No one else is seeing this?

David AD4TJ




Geza Szabados-Hann
 

Hi David,

it seems that nobody understood the meaning of the closing 73 if RRR procedure is used. The RRR procedure should make the communication be more reliable under bad conditions. The closing 73 *is* the key for it. The station receiving RRR should send 73 and should wait for receiving the closing 73. If the closing 73 not received, the station cannot be sure that the other station logged the QSO too.
I also obtained this behavior with earlier versions.  it seems to be a timing issue. WSJTX disables TX-enable before starting to send the closing 73.

Geza DG5LP.


Bill Somerville
 

On 24/03/2021 22:37, Geza Szabados-Hann wrote:
Hi David,

it seems that nobody understood the meaning of the closing 73 if RRR procedure is used. The RRR procedure should make the communication be more reliable under bad conditions. The closing 73 *is* the key for it. The station receiving RRR should send 73 and should wait for receiving the closing 73. If the closing 73 not received, the station cannot be sure that the other station logged the QSO too.
I also obtained this behavior with earlier versions.  it seems to be a timing issue. WSJTX disables TX-enable before starting to send the closing 73.

Geza DG5LP.
Geza,

your logic is flawed. If you expect a 73 message in reply to a 73 message then how does the sender know when to stop sending repeats? A better strategy is for the recipient of an RRR message to send one or more 73 messages, how many to send is a judgement call based on the progress of the QSO so far. The recipient of the RRR message has a small chance of logging an incomplete QSO but no greater than their QSO partner doing so if you fail to decode RRR messages up until the they give up sending them.

Bottom line is that not every QSO gets completed two-way in adverse conditions.

73
Bill
G4WJS.


Joe Subich, W4TV
 

On 2021-03-24 6:37 PM, Geza Szabados-Hann wrote:

The closing 73 *is* the key for it.
No! 73 in response to 73 is redundant and wasteful.

When the first station sends R-## he is already acknowledging the
calling station's report. When the calling station sends RRR
and the first station sends 73 *THE QSO IS COMPLETE*. If the
first station has not copied RRR, he doesn't sent 73, he sends
R-## *again* until he receives RRR.

There is no need for the calling station to send 73 in response
to the first station's 73. He has already received RRR and the
QSO *IS COMPLETE*.

IT SEEMS THAT MANY PEOPLE DO NOT UNDERSTAND WHAT A COMPLETE QSO IS.

73,

... Joe, W4TV


On 2021-03-24 6:37 PM, Geza Szabados-Hann wrote:
Hi David,
it seems that nobody understood the meaning of the closing 73 if RRR procedure is used. The RRR procedure should make the communication be more reliable under bad conditions. The closing 73 *is* the key for it. The station receiving RRR should send 73 and should wait for receiving the closing 73. If the closing 73 not received, the station cannot be sure that the other station logged the QSO too.
I also obtained this behavior with earlier versions.  it seems to be a timing issue. WSJTX disables TX-enable before starting to send the closing 73.
Geza DG5LP.


Gary - AG0N
 

On Mar 24, 2021, at 16:51, Bill Somerville <g4wjs@...> wrote:

your logic is flawed. If you expect a 73 message in reply to a 73 message then how does the sender know when to stop sending repeats?
I may not be an old timer at this, Bill, but he IS right. It has been used in this way on VHF MS operation since I got started in it almost 10 years ago when I retired. RRR waits for a 73 and the 73 waits for an acknowledging 73 to signal it is done. It is normal operation. It seems like every time we turn around, someone is trying to shorten the whole thing to be even faster. It’s like changing the rules mid stream to make it easier for people who are too lazy to wait for the whole process to properly complete. First we stick in RR73 to make it faster, then we say skip TX1 and start with TX2 on reply to a CQ. Another shortcut. Then we say RR73 needs no acknowledgement. Why don’t you just go full auto and work the world while you're off at the job? Many of us like the integrity of the full exchange.

Gary - AG0N


Jim Brown
 

On 3/24/2021 9:36 PM, Gary - AG0N wrote:
I may not be an old timer at this, Bill, but he IS right. It has been used in this way on VHF MS operation since I got started in it almost 10 years ago when I retired.
Hi Gary,

I also do lots of weak signal work on VHF and 160M, and I disagree with you, Gary. VHF/UHF is DIFFERENT from HF operation in many ways, including that conditions are often marginal and it can take 30-45 minutes to finish a MS QSO. The protocols that have evolved for VHF/UHF are entirely weak signal work with WSJT modes are appropriate for those bands, but they are overkill for HF.

The QSO is complete when both stations have copied R of the other station's exchange. The only question is about how that is communicated, and that depends on long established practice.

Consider this, Gary. In a CW or SSB contest or DX pileup on HF, when the CQing station in the contest or the DX station repeats his exchange it tells you that he did NOT copy your TU and exchange, and you repeat it. If he send your call and TU, he's listening for another call, and you're done. This is how it's been done on the HF bands for generations (I started out in contesting in 1957, and what I describe has been standard practice for at least 3 decades. When I got back on the air in 2003 after several decades running my sown mall biz, I instinctively responded to a CQ with my call and the other station came right back).

With WSJT-X modes, if he doesn't copy your RRR, he repeats your report (R-18). But if he DID copy your RRR or RR73, he calls CQ. If he didn't he would have sent R-18 again. The same applies with WSJT-X modes.

And, BTW, the vast majority of my VHF weak signal QSOs other than FT8 are coordinated on VHF-Slack (I used to use PJ), and it has long been considered good practice on any of these VHF/UHF chat sites for one station (usually but not always the guy in the rare grid) to say online, "got RRR. 73" to save time for the expedition to work more of the deserving. Remember -- it is the fact that he copied the other station's RRR that completes the QSO. There is NO requirement that one or both stations copy 73.

73, Jim K9YC


Geza Szabados-Hann
 

On Wed, Mar 24, 2021 at 04:25 PM, Joe Subich, W4TV wrote:
There is no need for the calling station to send 73 in response
to the first station's 73. He has already received RRR and the
QSO *IS COMPLETE*.
The QSO is complete if both QSO partners can be sure that the other station has logged the QSO. If a station selects to use the RRR procedure, the QSO (in contrast to RR73) is not logged on reception of the R-report, first when receiving the 73. If no closing 73 is sent, the other station can not be sure that the QSO was logged by the QSO-partner.
Using RR73 is the main reason for the many NILs. 

Geza DG5LP


Joe Subich, W4TV
 

On 2021-03-25 8:50 AM, Geza Szabados-Hann wrote:
If a station selects to use the RRR procedure, the QSO (in contrast
to RR73) is not logged on reception of the R-report, first when
receiving the 73. If no closing 73 is sent, the other station can not
be sure that the QSO was logged by the QSO-partner.
If that is your definition of a "complete" QSO, 90+ of CW/SSB DXpedition
and contest QSOs in the last 50 years are not "complete". A QSO is
complete when each station has received and acknowledged the report
from the other station. A QSO does not require an acknowledgement
of the report or and acknowledgement of the acknowledgement.

More 'good' "JT Mode" QSOs are abandoned because of some misguided
need for an acknowledgement of an acknowledgement than are logged
as "NIL".

73,

... Joe, W4TV


On 2021-03-25 8:50 AM, Geza Szabados-Hann wrote:
On Wed, Mar 24, 2021 at 04:25 PM, Joe Subich, W4TV wrote:
There is no need for the calling station to send 73 in response
to the first station's 73. He has already received RRR and the
QSO *IS COMPLETE*.
The QSO is complete if both QSO partners can be sure that the other station has logged the QSO. If a station selects to use the RRR procedure, the QSO (in contrast to RR73) is not logged on reception of the R-report, first when receiving the 73. If no closing 73 is sent, the other station can not be sure that the QSO was logged by the QSO-partner.
Using RR73 is the main reason for the many NILs.
Geza DG5LP