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