[CQ-Contest] World Wide Digi DX Contest Results.

[Stanley Zawrotny]

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 at 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 at contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest