[CQ-Contest] WWDIGI Contest Testing...

[Joe]

[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 <cq-contest-bounces at contesting.com> On Behalf Of Joe
> Sent: 29 July, 2019 06:41
> To: Contest Reflector <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