Always QRV, never QRU

QUIZ: what’s wrong with this QSO?

PublishedJune 30, 2014

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.

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.

6 Responses to QUIZ: what’s wrong with this QSO?

There is an old saying: “The job isn’t over until the paperwork is finished” and I think in contesting we are heading towards any error in a contest log submission means the submitter loses that QSO without other penalty – just as we did with dupes. Now, it would be nice if the log accepting “robot” did a check of the Cabrillo file and told the submitter there were Cabrillo errors, try again.

So, that would say it is *not* your job to fix those kind of errors. That would save your time for the more important “human interventions” which makes sense.

Any Cabrillo editing seems kind of odd. I don’t use TR4W, I’m an N1MM kinda guy. I’ve been playing around with remote operation and have ended up with two different N1MM logs for the same contest and to get the merged file to work I had to do some ADIF tweaking, but I can’t think of any reason I’d ever edit the Cabrillo file.

Hi John
I have written a ‘robot’ routine that checks a log upon reception in the email inbox but I only check if I can read it and if the fields are there. Content is not checked. Some errors only surface when doing the actual log checking. You’d be amazed how many logs are in local time i.s.o. UTC. I can only see that when comparing a log with a bunch of other logs.

I’m a true blue N1MMLogger user too. If everyone would use that, or at least a logger that follows the Cabrillo standard, my paperwork would be much less. Unfortunately there are a lot of smaller loggers out there that do weird things. Not to mention logs in Word, Excel, a PDF of a Cabrillo etc…

I feel and know your pain. We see the same kinds of things in the CQWW and CQ WPX logs. It would be nice if all of the files were perfect, but that doesn’t happen. Some of the errors do leave you scratching your head over how they could get into the log, but they do.

Since an invalid QSO line in one log can create a NIL in another log, you can’t just ignore these. The QSO happened – one guy just can’t make a valid text file. Better to just correct the text errors in the bad log and move on.

Only when we go to 100% online logging and real-time scoring will we get past this.

Your sympathy as administrator for the big contests that are WW and WPX, means a lot to me.
I only have to go through 800-1000 logs per contest, netting 200-250k QSO. I really would not want to go through this pain for 5000 logs with millions (?) of contacts.

Like you say there is a lot of head scratching to be done. I don’t understand what people do to their logs and how they log. There is one guy EVERY year that logs 200+ QSO on all bands, yet only submits 100 contacts as SBxx. If I don’t intercept that, all the other guys get a NIL. Speaking of NIL: that happens quite a lot too. And I also like the Belgian guy who logs OB9 on 3.7 MHz SSB in broad daylight. Or how about TR9A as a mult?

I must say that five years of log checking has made me a better operator because not only do I become a small walking SCP file, but I also have learned from the common mistakes people make.

Kudos for going through the trouble of dealing with cross band QSO’s. My favorite is when one end of the QSO isn’t using an interfaced radio, and manually changes the band in the logging program. But he does it after making a few QSO’s on the new band. Since he only generates a few NIL’s, the automated log checking doesn’t flag it.

My goal was to come up with as complete and accurate log checking as I could think of and write code for.
I must say that I have learned a lot by coming across very weird situations. This may sound a bit cocky, but some scenarios can’t be written by an experienced contester who knows what (s)he’s doing. I have the feeling that some operators just put something in the log because the software doesn’t accept voids.
That said, 95% of the two way contacts can be verified and approved by the automated process. Of the remaining 5% a good deal is automatically flagged as a bad call or a bad serial number. It took my a while at first to see why my own code wouldn’t accept a contact that had the right call, the right serial and was within time offset tolerance. Then it hit me: different bands! :o)