Peter,
Good comments.
The problem with the NILs is this: If you reply to my CQ, giving an RST and I
reply to you with RR and an RST, but I don’t hear your RR73......did you send
it and I didn’t hear it or didn’t you hear my exchange OR did you just go on to
the next guy without replying? The uses say that the info has to be exchanged.
So was it?
In RTTY (and in CW and in SSB), with Station A calling CQ, Station B calls
him. Station A sends his RST (and the rest of the exchange). Station B responds
with his exchange. Does Station A always respond that he has heard the exchange
from Station B by sending TU? No. Sometimes he goes straight into a CQ. Should
Station B log the Q or not? Station A did not send a 73 (or a TU). Usually
Station B will log the Q.
If it were an FT4 QSO, what’s the difference that A did or didn’t send RR73?
It’s a parallel situation. Yet many Station Bs will not log it because they
didn’t get a 73. Result: Station A gets a NIL AND station B didn’t get a
contact.
A second problem arises because if this uncertainty. Because A is not in B’s
log, he may try to call A again later. A may ignore B because B comes up as a
dupe. He may even be forced to ignore B if he has left the logger in the
default mode of not accepting dupes. Note that more and more contests are
instructing participants to leave dupes in the log.
Often, in an SSB contest, I will hear Station A say that their logger won’t let
them log a dupe. If station B got A’s call wrong, then A will get a NIL penalty
and B will just not get the Q. Always accept dupes. Arguing about it only
interrupts your flow. It’s not a dupe, it’s a correction. Be thankful for it.
Peter is partially right that software developers need to address these
deficiencies, but they are also educational concerns.
Stan, K4SBZ
"Real radio bounces off the sky."
> On Jan 12, 2020, at 2:26 PM, Peter Sundberg <sm2cew@telia.com> wrote:
>
> But there is a major problem when the contest committee tell us that they
> had to waive the NIL penalty because otherwise a large number of stations
> would end up with a negative score.
>
> Furthermore the committee states the following:
>
> "In the legacy modes, the "fault" for a NIL is most always on the side that
> logged the QSO. For
> the FT mode it is not yet clear where the fault is, but in any case, the
> amount of NILs is
> abnormally high. Going forward, FT contesting needs to better define how QSO
> partners can reliably
> communicate whether a QSO is complete and should be logged. The
> responsibility resides both
> with contest participants and FT contest software developers."
>
> Yes Vince, a contest is a contest and the goal is the same. But when the
> operator is unable to decide whether a QSO should be logged or not, to me it
> that's a clear indication that automation has gone too far. Especially when
> the committee says that the amount of NILs is abnormally high.
>
> The operator is "in the back seat" and certainly NOT up front driving. Now
> that's where there's clearly room for criticizing the concept.
>
> 73
> Peter SM2CEW
>
>
>
>
> At 15:20 2020-01-12, DXer wrote:
>
>> As for all the other FT-X 'non-user expert' criticism, a contest is a
>> contest. The goal is the same. Personal sub-interests are just that,
>> personal.
>>
>> 73 de Vince, VA3VF
>
>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|