[CQ-Contest] Sweepstakes log checking

[n6tr at teleport.com]

A few of you have asked for more details on the process used to bust
a callsign.

There are three primary ways that this can happen:

1. A busted call can be generated automatically by the software during
the cross checking process.  The best way to explain this is by 
given a hypothetical example:

Let's say K6LL has busted N2IC's callsign and has it as N2SC in his
log.

During the cross check of N2IC's log, the program will find a QSO
with K6LL.  It will then look in the K6LL log to see if it can find
N2IC at the expected QSO number.  Instead, it finds a call that looks
close to N2IC with the correct check and section.

In this case, the program will decide that the QSO in N2IC's log is
okay, but that the call N2SC is a bad call.

2. During the automated process of generating a database for the 
contest, some callsigns that were busted the same way by several 
people will make it into the database.  Calls with lots of S's and
H's tend to show up this way.  After I generate a database, I run
a procedure to show me calls that are similar to each other, with the
same exchange information.  In addition to listing the call, I am 
also shown the received QSO numbers for each of the calls.

If I see a call that doesn't follow the expected QSO number pattern,
then I suspect it of being a busted call of an active station.  

A typical example of a busted call would be seeing QSO numbers like 
this for a station:

    309
    427
    723
   1134

The typical pattern is more like this:

     1
     2
     4
     5
     7  etc.

I have seen busted QSO numbers like the first case grouped in a small
period of time (on hour or less).  My thoery is that these were spawned
by an incorrect packet spot.

3. After I have initially run all the logs through the process once, I
can view all of the "not found in database" calls and the other calls
that are found in the database with the same check and section.  I also
look at the QSO number received.  If I see something like this:

N2SC  352  N2IC  

This means someone got QSO number 352 from N2SC which isn't in the 
database and that N2IC is in the database with the same exchange 
information.

This would be a no brainer (on CW) to flag as a bad call.  Some of
the other calls need more work.

For example, in the WP3R log, there was a QSO with KS3F and KQ3F 
had the same check and section.  However, I had to look at the 
timing of the other QSOs and QSO numbers to decide they were indeed
different stations.  KS3F gave out QSO number 1 to WP3R when KQ3F
had 12 QSOs in his log.  Note that this process can be done even
when I don't have either log.  I hope to automate this process for
next year by including times and bands into the equation.

On CW, there are some very common mistakes that make up a large
percentage of the busted calls.  Anything with three or more dits
in it often causes the errors.  Call like KH7R will show up as K5ZR
and so on.  

On phone, the "no brainer" mistakes are different, and very interesting
to think about.  I hope to write more about this in the NCJ articles.

Whenever a call is flagged as being "bad" - it is only bad when enough
of the exchange information matches the "correct" call.  This was
necessary because sometimes a busted call might actually be a call
that was active.  This feature allows me to decide that N2SC would 
be a busted call if he was in Colorado, but not if he was sending
some other check and section.

During the processing of a very clean phone log (VE7SZ), I found
room for improvement.  There was a case where someone had logged
VE7BC instead of VE7SZ.  However, the QSO number and check/section
were that of VE7SZ.  The program flagged this as a NIL in SZ's log.

However, after improving the process, it will now flag VE7BC as
a busted call, and not as a NIL in SZ's log.  

So, if you are going to bust a call, you should also make sure you
bust the check and section as well - which makes it harder for me 
to figure out what it is.  The only problem, is that I am checking
99 percent of your checks and sections, so this will probably not
pay off in the long run!!

BTW, the database generation procedure was improved for SSB and 
essentially any call that shows up in two or more logs will be
in the database.  However, unless they agree on the exchange 
information, the call will be marked as unstable.  This is why
I have about 500 unstable calls in the SSB database!  I had to
also add unstable detection to the automatic routine because doing
it manually would have taken weeks.

Many have asked when the SSB reports will be available.  The answer
is probably around 1 April.

73 Tree N6TR
tree at contesting.com

>From n6tr Mon Mar  8 10:59:16 1999
To: k4sb at mindspring.com
Subject: SS log checking
Content-Length: 479


I am having a hard time understanding what "stinks" with the checking
process.

In the case of this:

> "W0DJC was not found in the SS database. Received QSO#=1. Calls with
> same check/section:  K0KX W0ZQ WA2MNO WE0Q W0GQ"
> "KB0VCV was not found in the SS database. Received QSO#=1"

neither of these calls are removed from the database.  

Please try to understand what is really going on here before you
react to people who haven't finished reading the fine print.

73 Tree


--
CQ-Contest on WWW:        http://www.contesting.com/_cq-contest/
Administrative requests:  cq-contest-REQUEST at contesting.com