RRR or RR73 is a trigger to log the QSO. If you don’t receive it, auto
sequence won’t log the QSO.
Typical CW QSO (using grids as an example)
Them: CQ TEST K5ZD
Me: N2RJ
Them: N2RJ 5NN FN42
Me: 5NN FN21
Them: TU
The TU is the ack. Without receiving TU I don’t know if the QSO is clean.
Equivalent in FT8 is RR73 or RRR. If I don’t receive those I don’t know if
QSO is clean.
You are right that the 2nd 73 is superfluous but there are people who
insist on it and who will deliberately not log you in order to teach you a
lesson.
BTW something else is that the grid exchange seems transposed in
traditional vs FT8 auto seq. The grid is sent on initial CQ in FT8 but not
in CW or SSB.
Ria
N2RJ
On Wed, Feb 26, 2020 at 10:23 PM Ed Muns <ed@w0yk.com> wrote:
> Each QSO partner only needs to ACK one time to confirm that they received
> the call and exchange of their partner. In the example below, I believe
> the “Common to both” is actually:
>
>
>
> CQ N2RJ FN21
>
> N2RJ K5ZD FN42
>
> K5ZD N2RJ -03
>
> N2RJ K5ZD R+02 ß K5ZD includes an ‘R’ ACK in his exchange message
>
>
>
> At this point all that is missing is an ACK by N2RJ that the call and
> exchange from K5ZD have been received. That is typically RR73, but could
> be RRR or 73 or R or whatever.
>
>
>
> R, RRR, RR73 and 73 are alternative ACKs. Just like in CW where TU, R,
> 73, EE, etc are all alternative ACKs , at the discretion of the operator.
>
>
>
> If a QSO partner indicates (by repeating a message) that they want to
> receive a third ACK, e.g., 73, then the other partner can choose to
> manually intervene and send an additional unnecessary 73 message in order
> to increase the probability that the QSO will be logged on both sides and
> avoid a NIL.
>
>
>
> Ed W0YK
>
>
>
> *From:* rjairam@gmail.com <rjairam@gmail.com>
> *Sent:* 26 February, 2020 18:31
> *To:* k5zd@charter.net
> *Cc:* Don Hill AA5AU <aa5au@bellsouth.net>; Iztok Saje <
> iztok.saje@telekom.si>; Joe Taylor <joe@princeton.edu>; Steven Franke <
> s.j.franke@icloud.com>; cq-contest@contesting.com; ed@w0yk.com
> *Subject:* Re: [CQ-Contest] FT4 and FT8 Contesting
>
>
>
> There are hard liners who will almost seem like they are punishing the
> other op for not sending a “73.”
>
>
>
> RR73 was a hack that became official then became standard. RR73 is encoded
> as a grid square in the software. But it is basically the same as a shot in
> the dark - other side won’t always know if you completed.
>
>
>
> The old format was more reliable but took a couple of extra cycles.
>
>
>
> Common to both:
>
> CQ N2RJ FN21
>
> N2RJ K5ZD FN42
>
> K5ZD N2RJ -03
>
> N2RJ K5ZD +02
>
>
>
> Old confirmation:
>
> K5ZD N2RJ RRR
>
> N2RJ K5ZD RRR <— optional
>
> K5ZD N2RJ 73
>
> N2RJ K5ZD 73
>
>
>
> 73 may be substituted for the optional RRR. Both sides did an ack
>
>
>
> New method:
>
>
>
> K5ZD N2RJ RR73 <—- transmissions end here, QSO is logged
>
> N2RJ K5ZD 73
>
>
>
> This lends itself to NILs easily.
>
>
>
> Ria
>
> N2RJ
>
>
>
> On Wed, Feb 26, 2020 at 8:56 PM <k5zd@charter.net> wrote:
>
> "The paper points out that a third ACK, e.g., '73' sent in response to a
> 'RR73' is unnecessary. Nonetheless, some operators, often casual
> operators,
> have come to expect a third ACK (73) is needed for QSO completion."
>
> I think you just made my point.
>
> Zd
>
>
> -----Original Message-----
> From: Ed Muns <ed@w0yk.com>
> Sent: Wednesday, February 26, 2020 8:46 PM
> To: k5zd@charter.net; cq-contest@contesting.com
> Cc: 'Steven Franke' <s.j.franke@icloud.com>; 'Don Hill AA5AU'
> <aa5au@bellsouth.net>; 'Iztok Saje' <iztok.saje@telekom.si>; 'Joe Taylor'
> <joe@princeton.edu>
> Subject: RE: [CQ-Contest] FT4 and FT8 Contesting
>
> Good comments, Randy.
>
> I've copied the paper's authors because some of them aren't regular
> subscribers to this list. The ideal protocol for QSO completion and
> logging
> differs by contest. Rather than specify a set of exact protocols covering
> all contests, we offered a list of the message content sufficient for a
> complete QSO. It is the same list that top CW, SSB and RTTY operators
> recommend. That is, both QSO partners exchange calls and exchanges plus an
> ACK (each) that the information was received.
>
> The paper points out that a third ACK, e.g., '73' sent in response to a
> 'RR73' is unnecessary. Nonetheless, some operators, often casual
> operators,
> have come to expect a third ACK (73) is needed for QSO completion. In
> those
> cases, they often repeat their RR73 message in order to elicit another ACK
> (73) from their QSO partner. An attentive QSO partner will pick up on that
> clue and manually send the unnecessary third ACK (73) to maximize
> probability that their QSO partner will log the QSO. This is an example of
> operator engagement and dynamic messaging that encourages skill development
> in FT contesting.
>
> NILs will never be eliminated, in any mode, because of the imperfect nature
> of radio propagation. Message delivery cannot be guaranteed, no matter how
> many ACKs are sent. Over decades of operation and contesting the NIL rates
> for CW, SSB and RTTY have settled in the range of 1-2%. When a QSO message
> is not copied, we ask for fills or repeat our last message. We've learned
> that if our QSO partner starts a new QSO right after we should have
> received
> their last message in our QSO, that that most likely means they logged the
> QSO. Our assumptions will never be 100% right, thus a small NIL rate.
> That's reality and what makes operating interesting and not a purely
> robotic
> activity.
>
> Currently, the FT NIL rate is significantly higher than the legacy modes,
> 4-6%. The first step of improvement is to reduce it to what the other
> modes
> have shown is feasible. There will always be the quest for a Golden log,
> balanced with speed.
>
> Ed W0YK
>
> -----Original Message-----
> From: k5zd@charter.net <k5zd@charter.net>
> Sent: 26 February, 2020 14:05
> To: ed@w0yk.com; cq-contest@contesting.com
> Subject: RE: [CQ-Contest] FT4 and FT8 Contesting
>
> Excellent summary. Thanks for all of you to make the effort to look into
> the higher than expected NILs in the Digi contests.
>
> I would have preferred to see the analysis go one step further and actually
> suggest a protocol for handling end of QSOs. The FT protocol is fixed, and
> the analysis assumes it is up to the operators, but just a bit more
> explanation of what people should do/expect would be very helpful for the
> community. Especially those ops that are new to FT contesting.
>
> I am quite sure things will improve as we all gain experience. I have
> learned a lot about how the better manage the QSO process just by doing
> more
> FT operating and really paying attention to the QSO flow and how to handle
> the edge cases that happen when you think you finished a QSO, started
> another, and then realize partner #1 is still looking for an ack. All part
> of the game I guess!
>
> 73
>
> Randy K5ZD
>
>
> -----Original Message-----
> From: CQ-Contest <cq-contest-bounces+k5zd=charter.net@contesting.com> On
> Behalf Of Ed Muns
> Sent: Wednesday, February 26, 2020 11:51 AM
> To: cq-contest@contesting.com
> Subject: [CQ-Contest] FT4 and FT8 Contesting
>
> Log checking for several recent contests that used the FT4 and FT8 modes
> has
> shown undesirably large numbers of claimed QSOs that receive not-in-log
> ("NIL") status from the other station. The WSJT development team has
> worked
> together with contest sponsors and log checkers to analyze the probable
> causes of these NILs. Our findings and some operating advice for future
> contests are posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_FT8_Contesting.pdf
> and will also appear in the May-June 2020 issue of NCJ, the National
> Contest
> Journal.
>
> 73 from the authors of the study:
>
> Steve Franke, K9AN
> Don Hill, AA5AU
> Ed Muns, W0YK
> Iztok Saje S52D
> Joe Taylor, K1JT
>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>
>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>
>
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|