CQ-Contest
[Top] [All Lists]

[CQ-Contest] Working dupes - log checker messed up

To: "cq-contest@contesting.com" <cq-contest@contesting.com>
Subject: [CQ-Contest] Working dupes - log checker messed up
From: Tree <tree@kkn.net>
Date: Thu, 12 Nov 2015 07:55:50 -0800
List-post: <cq-contest@contesting.com">mailto:cq-contest@contesting.com>
Certainly - there isn't any issue with working a dupe - and if you complete
a QSO on the air - it should be in your log.  DO NOT REMOVE IT after the
contest.

In the case that started this thread - with K3KU and VA3DF - I must fall on
my sword and admit this was an error on the part of the log checking
program.  Normally - the second QSO would match up - even if the times and
QSO numbers were different - and a NIL would not have been reported for
this case.

However, it appears that I have introduced a bug in the cross checking
procedure that somehow allowed this one case to be scored as a NIL.

In general - the cross checking routine goes to a lot of trouble to match
up QSOs. In the case of the SS - if the QSO numbers line up - the will
quickly find that and move onto the next QSO.  However, when the QSO is not
found where expected in the "target" log - a lot of work is done to try and
discover what happened.  Is there a busted callsign there?  (That is likely
how the busted call in K3KU's log was found - when doing the cross check
from VA3DF's log).  As different tests are done - one of the last ones is
to go through the whole log and see if the callsign shows up somewhere else
in the log (which would be the case where a dupe QSO wasn't logged by the
"target" callsign).

It appears that this final test was not executed because the program
decided incorrectly it knew what to do with the QSO before getting there.
I will have to spend some time analyzing this specific case to see exactly
what happened.

Despite doing the log checking for the SS for a number of years - the
program has been evolving over the year and trying to get better and
better.  One major change happened a few years ago where we changed a few
basic things on how the log checking got done in order to provide even more
accurate results.  Sometimes when we do surgery to take care of one
specific case - some other specific case ends up being handled differently
than we would expect.

When you see something strange like this in your report file - I am always
happy to take a look at it and see if it is a result of a programming
issue.  That is often how improvements get made.

There simply isn't time for a human to look over all of the report files
for these types of behavior.  I encourage everyone to take a look at their
report files and ask questions if something looks wrong.

73 Tree N6TR
n6tr@arrl.org
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest

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