[CQ-Contest] WWDIGI Contest Testing...

[Joe]

yeah ignore the "round," just what was default. sorry,

Joe WB9SBD
Sig
The Original Rolling Ball Clock
Idle Tyme
Idle-Tyme.com
http://www.idle-tyme.com
On 7/30/2019 2:51 PM, Ed Muns wrote:
>
> 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<cq-contest-bounces at contesting.com>  <mailto:cq-contest-bounces at contesting.com>  On Behalf Of Joe
>
>     Sent: 29 July, 2019 06:41
>
>     To: Contest Reflector<cq-contest at contesting.com>  <mailto: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
>