CQ-Contest
[Top] [All Lists]

Re: [CQ-Contest] FT4 and FT8 Contesting

To: k5zd@charter.net
Subject: Re: [CQ-Contest] FT4 and FT8 Contesting
From: "rjairam@gmail.com" <rjairam@gmail.com>
Date: Wed, 26 Feb 2020 21:30:58 -0500
List-post: <mailto:cq-contest@contesting.com>
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
<Prev in Thread] Current Thread [Next in Thread>