[CQ-Contest] WWDIGI Contest Testing...
Joe
nss at mwt.net
Tue Jul 30 16:06:32 EDT 2019
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
>
More information about the CQ-Contest
mailing list