Every year we hear the complaint about how much time is spent with badly
formatted e-logs -- and even more now that the log checking process is
actually trying to automate.
The ARRL (and CQ) need to rigidly specify a file format and then force
people to use it. We are talking about flat ASCII files that are easy to
create. There is no reason all of the logging packages can't generate
identical .LOG files. So, why don't they?
Because when neither contest committee has ever issued a firm directive as
to exactly what they want. Instead, they write their own conversion
utilities and deal with the problem. Then complain about how much time is
wasted.
One the same note, I would recommend that they issue a specification for
summary sheet information as well. This way a computer program could be
written to extract the necessary summary information and save another batch
of typos and errors. Look at the 1040PC form the IRS now uses as an
example.
I realize that even with these measures, many logs would still need work.
But the goal should be to move the log submission and checking process to be
fully automated. And the only way this can happen is to standardize the
input data.
Randy, K5ZD
> -----Original Message-----
> From: David A. Pruett [mailto:k8cc@ix.netcom.com]
> Sent: Friday, May 07, 1999 12:00 AM
> To: cq-contest@contesting.com
> Subject: [CQ-Contest] Checking your entry
>
>
>
> One item which has been missed in the discussion of
> post-contest checking
> of your log concerns making sure all of the default
> information in your
> entry is correct. Actually, this is a pre-contest task.
>
> What do I mean by this? Well, K9TM and I are writing the
> software to check
> the ARRL 10M logs for the ARRL. The ARRL format file spec (the
> callsign.LOG file) requires that the "sent information" be
> included in each
> QSO data line. Well, the log for a certain well-known
> Carribean contest
> station indicates that he sent "59 CA" for every exchange, whereas in
> compliance with the contest rules we strongly suspect that he
> sent "59" and
> a serial number. While this is a simple setup error on his
> part, its his
> responsibility to see that the entry was correct. What K9TM
> and I plan to
> do in this case is imply the serial number (i.e., the first
> QSO is #1, the
> second is #2, etc.). The danger here is that if a single QSO
> is hosed in
> the file, then the subsequent serial numbers are out of whack
> and there are
> gonna be a whole lot of lost QSOs. Dunno how else to treat this.
>
> The contesting community might be deeply embarrassed if they
> knew the sorry
> state of the logs being submitted. Out of almost 1400 computer logs
> submitted for the ARRL 10M contest, only about 300 are in a
> usable ARRL
> format as submitted. We have been able to identify about 400
> more logs, a
> mix of the various ASCII output log files generated by the popular
> programs, and write some conversion programs to translate the data.
> However, this means that roughly 50% of the E-logs are in a
> format that we
> can't identify. You can't imagine the amount of work going
> into this task
> (OK, so N6TR and N5KO probably do...).
>
> When the ARRL 10M writeup comes out, there will be a sidebar
> explaining
> exactly what you need to submit to the ARRL for as many of the popular
> packages and we can figure out. Hopefully, this will clear
> up some of the
> confusion. However, its the responsibility of the entrant to
> make sure his
> or her file is in the correct format! All of the current "big three"
> (CT/NA/TR) generate good data, but some older versions
> generate incomplete
> files. It pays to have the latest version of your favorite
> package. At
> some point, I suspect the ARRL (and maybe CQ too) are going
> to have to draw
> the line.
>
> 73,
>
> Dave/K8CC
>
>
> --
> CQ-Contest on WWW: http://www.contesting.com/_cq-contest/
> Administrative requests: cq-contest-REQUEST@contesting.com
>
--
CQ-Contest on WWW: http://www.contesting.com/_cq-contest/
Administrative requests: cq-contest-REQUEST@contesting.com
|