Folks,
I can vouch for the usefulness of RRR on FT8 in certain situations, such as running QRP 5 Watts. I often found, as a QRP station, that I needed to run with RRR as my default TX4 message to ensure the other end heard my reply and confirm a contact, otherwise they may miss the RR73 and are then unsure if I ever heard them at all. (QSO lacks 2-way confirmation). This if course reflects the intent in the manual as well. I, in fact, have just spent 6 weeks on air as a QRP portable station operating around the UK and often found I had to switch TX4 to RRR mode to complete QSOs reliably, so I can vouch for this from firsthand experience. I agree that the [xxx] [xxx] 73 TX5 message is (or can be) somewhat redundant and should not be relied upon as a QSO log indicator. If you have seen or sent RR73 then the QSO should be logged at that point, and not wait for the 73. However, if there was any improvement, my suggestion would be to amend the automation so that if you sent someone an RR73 (Tx4), and the next over they replied with the TX3 message again, that the automation automatically switch TX4 to RRR mode. Further, at that point, it should keep responding to the TX3 each over until either an over passes where no TX3 is received, a watchdog timeout occurs, or the sending station finally replies with a TX5. As soon as a new QSO starts, then revert TX4 back to RR73 mode. This should in my opinion increase the QSO completion chances under challenging weak signal/channel congestion circumstances. Next, as for abandoning TX5 completely, it is useful to send free text, particularly if you are running a compound call (as I was recently as M/VK5GR/P). In that case TX5 was used to send strings like “IO70 QRP 73” or “GFF-0247 73” to inform the station being worked of the extra QSO data that is lost (like GRID for example) when you are running a compound call. I would therefore not advocate for removal of TX5. It has its place, although I agree it is probably being mis-handled by many currently. Finally, the automation protocol change I outlined above is something I would like to see added to FT4 as well. The reason is again many times using FT4 I have replied with RR73 in TX4 to someone and the very next over they still send me TX3 – to which I will simply not reply without manual intervention. Manual intervention in FT4 is hard to get the right settings in place to send the correct answer in time for the next over (e.g. reactivate the TX in the inter-frame TX gap). It would help potentially reduce the chaos when contesting with FT4 as well IMHO as there would be less “broken” QSOs (where one end things the other end hasn’t logged the exchange) while the original station was happy after sending RR73 and has moved onto the next QSO. It might slow QSO over rate down, but it might also improve QSO completion reliability. This probably could be open to some more debate that, but it is something I suggest should be considered. Regards, Grant VK5GR From: Sam W2JDB via wsjt-devel <wsjt-devel@lists.sourceforge.net> Sent: Monday, October 23, 2023 12:50 AM To: wsjt-devel@lists.sourceforge.net Cc: Sam W2JDB <w2...@aol.com> Subject: Re: [wsjt-devel] No 73 allowed after RR73? >From the WSJT-X User guide: Section 7.1 : Standard messages - " The RR73 message should be used only if you are reasonably confident that no repetitions will be required." Section 7.4 : Contest messages - "Always log a QSO when you have received RRR, RR73, or 73 from a station you are working." "Log a QSO when you send RR73 or 73 if you are reasonably confident it will be copied. But be sure to watch for any indication that it was not copied, and then take appropriate action. For example, if you receive the Tx3 message (R plus contest exchange) again, and if you have activated the Alternate F1-F6 bindings, hit F4 to re-send your RR73." 73, Sam W2JDB On Sunday, October 22, 2023 at 08:58:15 AM EDT, Black Michael via wsjt-devel <wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > wrote: It's not a waste of time.... Here's why (especially on weak signals or when the band is flaky or QRM). .....start of QSO.... W9MDB W0YK R-13 W0YK W9MDB RR73 -- band goes flaky but I'm supposed to think the QSO is done...but you don't decode the RR73. W9MDB W0YK R-13 -- you repeat because you didn't get the RR73 but since our path is flaky I don't get this R-13 so I still think I'm done. W9MDB W0YK R-13 -- you repeat again -- I still don't receive you ad nauseum until you give up. I logged you because I sent RR73 and got no other message from you. You didn't log me as you never received RR73. If had sent RRR instead I would repeat 73 until I got your 73. That's why it says only use RR73 on a strong signal that you don't expect to have any problems with. Mike W9MDB On Sunday, October 22, 2023 at 12:09:40 AM CDT, Ed W0YK via wsjt-devel <wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > wrote: RR73 completes the QSO. Both QSO partners have sent calls, exchanges and QSLs. Am additional 73 message is a waste of time. 73, Ed W0YK -------- Original message -------- From: sdegroff via wsjt-devel <wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > Date: 10/21/23 13:18 (GMT-08:00) To: WSJT software development <wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > Cc: sdegroff <sdegr...@reagan.com <mailto:sdegr...@reagan.com> > Subject: Re: [wsjt-devel] No 73 allowed after RR73? I don't know what F/H is, but i have seen wsjtx hang and not complete the qso after RR73. Stan DeGroff W8SRD Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: Andy Durbin via wsjt-devel <wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > Date: 10/21/23 3:49 PM (GMT-05:00) To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> Cc: Andy Durbin <a.dur...@msn.com <mailto:a.dur...@msn.com> > Subject: [wsjt-devel] No 73 allowed after RR73? WSJT-X ver 2.6.1, Win 8.1. I have observed several times that I could not complete a QSO by sending 73 after I had received an RR73. This is expected operation with F/H active but not when F/H is not active. I suspect that something is latched in software if F/H mode has been used but is then exited and WSJT-X is not re-started. Has anyone else seen this or have an explanation? 73, Andy, k3wyc _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
