CQ-Contest
[Top] [All Lists]

Re: [CQ-Contest] WWDIGI Contest Testing...

To: ed@w0yk.com, 'Contest Reflector' <cq-contest@contesting.com>
Subject: Re: [CQ-Contest] WWDIGI Contest Testing...
From: Joe <nss@mwt.net>
Date: Tue, 30 Jul 2019 15:06:32 -0500
List-post: <mailto:cq-contest@contesting.com>
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@mwt.net>
*Sent:* 30 July, 2019 12:22
*To:* ed@w0yk.com; 'Contest Reflector' <cq-contest@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@contesting.com>  
<mailto:cq-contest-bounces@contesting.com>  On Behalf Of Joe

    Sent: 29 July, 2019 06:41

    To: Contest Reflector<cq-contest@contesting.com>  
<mailto:cq-contest@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


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

<Prev in Thread] Current Thread [Next in Thread>