[CQ-Contest] FT4 and FT8 Contesting

Wed Feb 26 22:23:06 EST 2020

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 at gmail.com <rjairam at gmail.com> 
Sent: 26 February, 2020 18:31
To: k5zd at charter.net
Cc: Don Hill AA5AU <aa5au at bellsouth.net>; Iztok Saje <iztok.saje at telekom.si>; Joe Taylor <joe at princeton.edu>; Steven Franke <s.j.franke at icloud.com>; cq-contest at contesting.com; ed at 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 at charter.net <mailto:k5zd at 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 at w0yk.com <mailto:ed at w0yk.com> > 
Sent: Wednesday, February 26, 2020 8:46 PM
To: k5zd at charter.net <mailto:k5zd at charter.net> ; cq-contest at contesting.com <mailto:cq-contest at contesting.com> 
Cc: 'Steven Franke' <s.j.franke at icloud.com <mailto:s.j.franke at icloud.com> >; 'Don Hill AA5AU'
<aa5au at bellsouth.net <mailto:aa5au at bellsouth.net> >; 'Iztok Saje' <iztok.saje at telekom.si <mailto:iztok.saje at telekom.si> >; 'Joe Taylor'
<joe at princeton.edu <mailto:joe at 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 at charter.net <mailto:k5zd at charter.net>  <k5zd at charter.net <mailto:k5zd at charter.net> >
Sent: 26 February, 2020 14:05
To: ed at w0yk.com <mailto:ed at w0yk.com> ; cq-contest at contesting.com <mailto:cq-contest at 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 at contesting.com <mailto:charter.net at contesting.com> > On
Behalf Of Ed Muns
Sent: Wednesday, February 26, 2020 11:51 AM
To: cq-contest at contesting.com <mailto:cq-contest at 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 at contesting.com <mailto:CQ-Contest at contesting.com> 
http://lists.contesting.com/mailman/listinfo/cq-contest

_______________________________________________
CQ-Contest mailing list
CQ-Contest at contesting.com <mailto:CQ-Contest at contesting.com> 
http://lists.contesting.com/mailman/listinfo/cq-contest