[CQ-Contest] WWDIGI Contest Testing...

Ed Muns ed at w0yk.com
Tue Jul 30 22:52:10 EDT 2019


To repeat a third time, sending '73' is not being advocated.  Rather
confirmation of receipt of the exchange is being recommended.  Confirmation
can be done any number of ways, including 'TU', 'R', '73', 'RR73', etc.  The
CW and FT8 sequences below include such confirmations. 

In the FT8 example below, transmission 4. is labeled optional.  That is
NC6K's receive cycle, so what is the benefit of W1AW not sending a message
to confirm that he received NC6K's report?  How else will NC6K know that
W1AW received the report and (probably) logged the QSO?  This illustrates
one of the key distinctions between WSJT-X modes and classic CW/SSB/RTTY
modes.  FT4/8 has fixed TX/RX periods and no time is saved by one of them
being empty.

The purpose of '73' in this discussion thread is for the confirmation by
W9ET of N9UDO's report.  For confirmation purposes, anything is fine: TU, R,
73, RR73, etc.  However, the Auto Seq feature of WSJT-X is expecting 'RR73'
in order to complete and log the QSO.  Because 73 was sent instead of RR73,
N9UDO's Auto Seq feature kept resending his report, attempting to get W9ET's
software to send 'RR73'.  That was the OP's original concern and question.

A complete QSO includes confirmation by both QSO partners.  Yes, some
contesters think they achieve higher rate by omitting 'R' or 'TU' on CW or
'thanks' on SSB, rationalizing that their exchange or subsequent CQ implies
a silent QSL message.  Yet, it is interesting to note that most Top Ten
finishers do include an explicit QSL and it doesn't keep them from winning.
The upside is that it removes uncertainty about whether the QSO was complete
and logged.  Many of our QSO partners are "non-contesters" or new contesters
and could be confused by not receiving an explicit QSL.

There is a middle ground when the rate is crazy high that the running
station may simply give their call (no TU, CQ or QRZ) or omit their call and
only send 'R' or 'thanks' for 2-3 quick QSOs before sending their call
again.  Outside of these rare situations, the miniscule time saved is not
worth the possible ambiguity of whether the QSO was completed.

Ed W0YK

-----Original Message-----
From: egruff at cox.net <egruff at cox.net> 
Sent: 30 July, 2019 16:03
To: ed at w0yk.com; 'Tim Shoppa' <tshoppa at gmail.com>; cq-contest at contesting.com
Subject: RE: [CQ-Contest] WWDIGI Contest Testing...

I always say I'm not going to get involved in these arguments and then I do
anyway, so here goes:

CW contest:

1. Me: CQ TEST NC6K
2. Them: W1AW
3. Me: W1AW 5NN SDG (for example)
4. Them: TU 5NN CT
5. Me: TU QRZ NC6K

No 73 anywhere and he confirms my report by sending mine (and TU if he feels
like it, but not everyone does. I often get "5NN CT" and nothing more). I
confirm with TU QRZ, but again the "TU" is a courtesy and not required.
Contesters tend to know that if the running station sends CQ, the Q is
complete and logged. Rate is key, and no one's trying to be rude.

On FT8:
1. Me: CQ TEST NC6K DM13
2. Them: NC6K W1AW FN31
3. Me: W1AW NC6K R DM13
4. Them: NC6K W1AW 73 (I consider this optional, but it makes me feel better
to see it as I know they got my last sequence)
5. Me: CQ TEST NC6K DM13

Why is this a problem? As long as both sides have indicated explicitly or
implicitly that the other's exchange was received, all should be FB. Why
belabor the process by adding another pair of 73 exchanges that might not
get decoded? In a contest, you're killing 30 seconds on FT8 and 12 seconds
on FT4. We certainly don't do it on RTTY.

At the risk of being rude, I really don't understand ops with the attitude
that they won't log a QSO unless everyone sends 73. This is a hobby. We're
here to have fun. Lighten up.

73 de NC6K

-----Original Message-----
From: CQ-Contest <cq-contest-bounces at contesting.com> On Behalf Of Ed Muns
Sent: Tuesday, July 30, 2019 12:17 PM
To: 'Tim Shoppa' <tshoppa at gmail.com>; cq-contest at contesting.com
Subject: Re: [CQ-Contest] WWDIGI Contest Testing...

Yes, "73" is not explicitly required.  However, that's only part of the
issue here.

Long-time QSO convention is that both sides QSL (confirm) the contact,
specifically that they received the required exchange.  In the case being
discussed, W9ET's 73 message served as his QSL.  Otherwise, N9UDO would not
know if W9ET copied the report.  In the classic modes, the 73 could have
been 'R' or 'QSL' or "thanks", etc.  But W9ET needs to send something that
conveys the report was received from N9UDO.  '73' satisfies that
confirmation convention.

Ed W0YK

-----Original Message-----
From: CQ-Contest <cq-contest-bounces at contesting.com> On Behalf Of Tim Shoppa
Sent: 30 July, 2019 09:25
To: cq-contest at contesting.com
Subject: Re: [CQ-Contest] WWDIGI Contest Testing...

On the subject of "it can't be a valid contact without a 73, can it?", there
was a QST "The World Above 50 MHz" column on the FT8 contest operations,
that led off with the re-assurance that there is no contest or DXCC rule
that requires 73 be sent or received to have a valid contact.

I did a spit-take when I read that and looked to make sure it wasn't an
April issue! But it wasn't an April issue!

Joe, for sure, "stalled out" FT8 contacts where the two sides are out of
sync results in wasted time and often you often don't get the same "meeting
of minds" that a two-way QSO had been completed that you get from the other
modes. At some point you have to decide whether to put the stalled out Q it
in the log or not and move to the next Q. And often 3 or 5 minutes after you
put it in the log and moved on, the guy comes back with the final
confirmation you wanted to hear (undoubtedly after you've made another
couple Q's.)

Tim N3QE
_______________________________________________
CQ-Contest mailing list
CQ-Contest at contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest

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



More information about the CQ-Contest mailing list