What’s up with ON5ZO? Same old same old. Still no RF / HF activity here. With the last QSO being made in WPX CW, it is about time to sink into the chair and make some contacts. Zero log entries in June, this will cost me dearly in the UBA Prefx Hunt.
The only thing I am doing for the hobby right now is checking the UBA CW logs. With 300k QSO, this is a huge task. Well, in fact it runs automatically for the normal contacts that can be cross-checked or verified. This is an eight hour job for my laptop, just like loading the logs from Cabrillo. Two overnight jobs. But there are about 1500 QSO that need manual judging. These are mostly busted calls and genuine ‘not in logs’.
I have been thinking about an algorithm that can intercept a busted call. If I see SH3EO I know it should be S53EO. But how to make the software find this (=easy part) without any mistakes (=hard). After all I can only do a check automatically if I can be 100% sure it won’t mark a QSO as bad when in fact it’s not. Right now these busts are found automatically if the serial numbers (and band and time +/- acceptable offset) match. That’s easy. But if one or both of the serial numbers are off between both logs, it hard to find a busted call by software. I need to manually check the log then, and not look at serial numbers but centered around the time stamp of the QSO I am checking. Assuming both logs have the correct UTC time which is not always the case either. See below!
Most of the time it boils down to a busted call or a simple ‘not in log’ (NIL). Quite often this is combined with one or both of the serial numbers wrong. It is almost impossible to have this accurately checked by software without any human intervention. So there is still a huge number of contacts that needs human judging. This takes time and I must admit it isn’t the most funny activity. But we’ll get there in the end.
Now what about the title of this post? I just came across this blog post about date and time (“Falsehoods programmers believe about time“) and the mistakes programmers make. I must admit there are several pits I fell into when writing the log checking code. Stuff like “Time stamps will always be specified in the same format” or “The system clock will always be set to a time that is not wildly different from the correct local time”, or “Well, surely there will never be a change to the time zone in which a program hast to run in production“. True oh so true when applied to contest logging computers and Cabrillo logs…
One reply on “Same old same old – Date and time”
Time errors are one of the biggest difficulties in checking the WPX logs. Some logs will have the whole log off by some time. Those are easy to adjust. It is the logs where random QSOs are off because the numbers were typed wrong, or a string of 10 QSOs are off by an hour, or the computer just assigned the same time to 5 QSOs in a row, that cause the most problems. But, time is a critical element in comparing two logs for a QSO so you have to find a solution and fix these problems first before you do the real log checking. Its an interesting programming challenge.