[CQ-Contest] WWDIGI Contest Testing...

[Ed Muns]

WSJT-X pre-loads the following default messages for the NA VHF Contest mode,
which is the recommended WSJT-X mode for the 2019 WW Digi contest:

 

                Tx 1: W9ET N9UDO EN53

                Tx 2: W9ET N9UDO EN53

                Tx 3: W9ET N9UDO R EN53

                Tx 4: W9ET N9UDO RR73

                Tx 5: W9ET N9UDO 73

                Tx 6: CQ TEST N9UDO EN53

 

The WW Digi rules do not require this message sequence, but it is programmed
into WSJT-X that most people will be using.  It behooves everyone to use the
same message sequence so that Auto Seq works well and the problem you
originally posed does not happen.  If the problem does happen there is an
easy way out as explained in the prior posting.

 

Perhaps you mis-typed your original posting, where you wrote "W9ET responds
by sending 73 round".  It's not clear what those words mean, but I guessed
you meant that message Tx 5 was sent, rather than Tx 4.  Since you also said
that N9UDO kept resending his Tx 3 report message, that indicates that N9UDO
was using Auto Seq and expecting to get a Tx 4 message from W9ET instead of
the Tx 5 message.  Yes, N9UDO might have been resending his Tx 3 message
because he didn't copy W9ET's 73 message, but that is much less likely.

 

If I misunderstood your scenario and question(s), please clarify and I'll
try again.

 

Ed W0YK

 

From: Joe <nss at mwt.net> 
Sent: 30 July, 2019 12:22
To: ed at w0yk.com; 'Contest Reflector' <cq-contest at contesting.com>
Subject: Re: [CQ-Contest] WWDIGI Contest Testing...

 

[Please explain the questions below.]

On 7/30/2019 12:12 PM, Ed Muns wrote:

Both W9ET and N9UDO contributed to this "less than ideal" QSO sequence.
W9ET didn't follow the default message sequence 

[What is the default sequence? I let WSJT-X do what it had in it, I (we
changed nothing) and according to the contest sponsor the exchange is,,,
III. CONTEST EXCHANGE: 4-character Grid Square.

So what was wrong?]



which required N9UDO to take
abnormal action.  N9UDO failed to take that abnormal action which would have
compensated and finished the QSO with no extra cycles.

[what would he do differently?]



 
 
W9ET's deviation from the default message sequence set up the problem
because it interrupted the Auto Seq function that N9UDO apparently had
enabled to methodically sequence through the default messages for WW Digi.

[what are the default messages for this contest all I found was "III.
CONTEST EXCHANGE: 4-character Grid Square."
But nothing on what should be in the sequences, Please?]



 
In theory, W9ET's 73 message is a satisfactory "QSL message" for N9UDO.
But, that would have required N9UDO to manually intervene and truncate the
resending of Tx 3. 
 
The Auto Seq function in WSJT-X is critical for effective QSOs because there
is inadequate time between reading a received message and starting the next
transmission. 

[especially in FT4, so the reason we changed NOTHING in WSJT-X] What should
it be?]



 The operator simply doesn't have enough time to read the
incoming message, decide what message to respond with and then select that
message before the transmission cycle begins.  This is a fundamental
difference compared to the classic CW/SSB/RTTY modes where (1) the message
unfolds from beginning to end of the message transmission, and (2) the
operator can delay transmission until she selects the appropriate response
message.  The FT message does not print ANYTHING until the end of the
reception cycle, leaving 1-2 seconds to react before the synchronized
transmission begins.
 
The current recommendation is for everyone to (1) use the default messages
for WW Digi,

[And what is that?]



 and (2) enable Auto Seq.  This way, both QSO partners know what
to expect and the Auto Sequencer will step through the necessary QSO phases
without incident.  When one QSO partner doesn't receive the expected next
message, his Auto Seq function simply resends his current message until he
receives the expected next message.  After some number of retries, it will
give up or the operator can intervene to abort a "stuck" QSO.
 
As for a "work-around", N9UDO could have recognized that W9ET's 73 message
was a sufficient QSL message and intervened with the Auto Seq function to
abort resending Tx 3 and log the QSO.
 
Bonus comment ...
Note that Tx 5 is not really needed for the current QSO (it is a second
redundant QSL from N9UDO), but it serves as a "CQ" for other stations to
call in.  However, other stations who want to speed things up will call
N9UDO (on a different frequency) in the same TX cycle as when W9ET sends
RR73 (Tx 4).  Then, N9UDO can send Tx 3 to the new caller without going
through a CQ/pileup sequence.  This will save two cycles, 30 seconds in FT8
and 15 seconds in FT4.  It's analogous to tail-ending in CW/SSB/RTTY but is
much more effective in the FT modes because callers can be on different,
clear frequencies to completely avoid QRMing each other.
 
This thread is probably better suited for the RTTYDigital reflector or
perhaps the WSJTdeveloper reflector.
 
Ed W0YK
 
-----Original Message-----
From: CQ-Contest  <mailto:cq-contest-bounces at contesting.com>
<cq-contest-bounces at contesting.com> On Behalf Of Joe
Sent: 29 July, 2019 06:41
To: Contest Reflector  <mailto:cq-contest at contesting.com>
<cq-contest at contesting.com>
Subject: [CQ-Contest] WWDIGI Contest Testing...
 
I was testing my set up with a few locals for the Up-Coming WWDIGI 
Contest, and we discovered something, that is NOT a HUGE issue, but 
looking for a workaround.
 
here is what happened.
 
N9UDO calling CQ
 
W9ET answers CQ with 'N9UDO W9ET EN43'
 
N9UDO replies with 'W9ET N9UDO R EN53'
 
W9ET responds by sending 73 round
 
N9UDO does not hear the 73 and keeps re-sending 'W9ET N9UDO R EN53'
 
W9ET is not aware that this is happening because it's TX has been turned 
off because the contact was logged. And W9ET is off looking for the next 
S&P to try to get.
 
This is with the N1MM+ & WSJT-X set up. Running with the Auto Log box 
checked and the special contest with the NA VHF chosen.
 
N9UDO can manually add the EN43 and manually log the contact,
 
Thinking if the 73 is it a must have for a valid contact?  if so, maybe 
the W9ET side should not shut off the TX enable button till it gets the 73?
 
or how should this situation be handled?
 
Joe WB9SBD