A couple of years ago, OT1A introduced me to the Pareto principle. Since then I have often applied this to the many obscure things I encounter while processing and checking the UBA DX contest logs. I think the ratio is even more skewed. 95% of my time is needed to fix 5% of the tampered logs or write extra code to handle these exceptions. I have ranted about this before.
I came across a LZ1 who had a NIL for a QSO with a RK9. In order to perform a cross check, my log checking software showed me a part of the RK9 log centred around the time the contact supposedly took place.
The RK9 log in my database showed:
QSO: 3500 CW 2014-02-22 2225 RK9### 599 004 SP*** 599 221 QSO: 3500 CW 2014-02-22 2227 RK9### 599 006 SF*** 599 396
Where is QSO #5 with LZ1? So I opened the submitted Cabrillo file and behold:
QSO: 3500 CW 2014-02-22 2225 RK9### 599 004 SP*** 599 221 QSO: 3500 CW 2014-O2-22 2226 RK9### 599 005 LZ1** 599 513 QSO: 3500 CW 2014-02-22 2227 RK9### 599 006 SF*** 599 396
What’s wrong with the line of QSO #5 in the Cabrillo file? I know. Do you see it? And more importantly: how on earth can this happen as long as you don’t mess with your log file? The RK9 log was made with TR4W. I can hardly imagine this logger randomly mutilates Cabrillo files?
I have made my code check the dates, and if it isn’t a valid date / time within the contest period, the contact is ditched and marked as ‘outside of the contest period’. I said it before and I’ll say it again: a few years ago there was actually a February 31 as the QSO date!!! However I seem to have assumed that dates would be numerical so my checking is actually too strict. Hence the code skipped the QSO.
I had already put in some code to handle serial numbers like ‘TNA’ for 091 which actually occur in the Cabrillo log files. Question is: is it my job to trap and fix messed up files, so in the end the guy who doesn’t even submit standard Cabrillo gets credit? Or does a corrupt log or a part thereof lead to decreased score? By all means a messed up log should not lead to loss of points in the other guy’s log.
I wonder how much of these things occur in all the logs combined. Not much, if any since I would have noticed this earlier. Most of the time, so except for this QSO, an automatically generated NIL is either a traceble busted call that gets flagged by the human checker (me) after the ‘robot’ checked the contacts that can be verified, or a true NIL. It just isn’t there.
Or it can be a cross band contact because one of both parties logged the contact on the wrong band. Yes that still happens in 2014. Then I need to compare both logs around the time the contact took place and see who is right and who is wrong. A human intervention is needed (me again). In most cases, by comparing the contacts, it’s clear who is right and who is wrong. Except when the contact is the running guy’s last contact before QSYing to another band that happens to be the band the S&P guy logged the contact on. Again the rule is: if a contact is not 100% proven bad, it counts. But this really is a 99.99% – 0.01% Pareto situation.