[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> On Behalf Of Joe
Sent: 29 July, 2019 06:41
To: Contest Reflector <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
|