[Ed Muns] All true, but …
From: rjairam@gmail.com <rjairam@gmail.com>
Sent: 27 February, 2020 06:59
To: ed@w0yk.com
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; k5zd@charter.net
Subject: Re: [CQ-Contest] FT4 and FT8 Contesting
RRR or RR73 is a trigger to log the QSO. If you don’t receive it, auto sequence
won’t log the QSO.
[Ed Muns] Auto-sequencing is an operator convenience that can be over-ridden as
appropriate based on the operator’s attention to each specific QSO. Note that
some FT software, e.g., DigiRite, can automatically send the unnecessary 73
message when a repeat RR73 (or other ACK) message is received. Still, the
operator should be diligently watching to be sure the best messaging is used
for the situation.
Typical CW QSO (using grids as an example)
Them: CQ TEST K5ZD
Me: N2RJ
Them: N2RJ 5NN FN42
Me: [Ed Muns] TU 5NN FN21[Ed Muns] <-- TU or R is recommended for clarity,
though some leave it implied
Them: TU [Ed Muns] Some ops will instead send ‘K5ZD’ only, especially in high
rate periods where their call sign (only) implies the ACK and CQ for next
callers. In general, though, an explicit ‘R’ or ‘TU’ or ‘73’ are preferable
for maximum clarity and lower NIL rates.
The TU is the ack. Without receiving TU I don’t know if the QSO is clean.
[Ed Muns] And, without the TU or R in N2RJ’s exchange message above, K5ZD is
less sure you have ACK’d his exchange. Best practice, in any mode, is for each
QSO partner to explicitly send an ACK that the call and exchange were received.
Equivalent in FT8 is RR73 or RRR. If I don’t receive those I don’t know if QSO
is clean.
[Ed Muns] These are most common but 73 or R or TU can be used. Any of them
provides the second ACK for the QSO.
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.
[Ed Muns] As stated in a prior posting, this is a good reason for the operator
to not treat FT QSOs robotically, but to pay attention and intervene with an
unnecessary 73 message to avoid a NIL.
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.
[Ed Muns] Yes, and when the CQer doesn’t send their exchange with the CQ
message, the S&Per sends their exchange with their initial call, which is also
backwards from typical legacy mode QSO sequencing.
Ria
N2RJ
[Ed Muns] Ed W0YK
On Wed, Feb 26, 2020 at 10:23 PM Ed Muns <ed@w0yk.com <mailto: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 <mailto:rjairam@gmail.com> <rjairam@gmail.com
<mailto:rjairam@gmail.com> >
Sent: 26 February, 2020 18:31
To: k5zd@charter.net <mailto:k5zd@charter.net>
Cc: 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> >; Steven Franke
<s.j.franke@icloud.com <mailto:s.j.franke@icloud.com> >;
cq-contest@contesting.com <mailto:cq-contest@contesting.com> ; ed@w0yk.com
<mailto: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
|