I have been watching the messages regarding the PA QSO party
fly by and there have been many interesting points raised.
This comment caught my eye and I would like to add a little:
Mike Coslo <mjc5@psu.edu> wrote:
"You mention 'cabrillo or something'. I'll fill you in on one of
contestings dirty little secrets.
There is cabrillo, and there is Cabrillo. Many amateurs trot out
the
word as some sort of Mantra, believing that it solves all problems. It
don't. We do indeed take cabrillo logs, and you won't see hardly two of
them alike."
I know a little about the Cabrillo format as I have written a
contest log processor that produces Cabrillo files called Cab-converter.
Indeed, there is no one "Cabrillo" file format definition that has a
crisp enough definition to be rightfully called a STANDARD. Or, to coin
a popular turn of phrase in the computer industry, "The best thing
about standards is everybody can have their own." It is, at best, a
collection of contest-specific file formats all collectively named
Cabrillo. It is, at worst, just a name for the particular file format
that one particular contest log processing robot _might_ consume
successfully. In either case, I agree completely with Mike Coslo, just
throwing the name "Cabrillo" around doesn't really address the problem.
The problems, as I see them (and are not specific to the PA QSO party)
are:
1. Not everybody uses a computer to do logging. You have to
handle this case.
2. The Cabrillo "standard" isn't. You still have to define PRECISELY
what contestants need to produce to create a successful submission.
Then you need to get software on the user's end to produce it.
3. Most contests have a submission process that is OPEN LOOP. The
robot may
kick it back a submission as "unreadable" or missing some element
(such as
your ARRL section), but few robots give you any feedback beyond
"got it".
The third problem is probably one of the biggest, in my view. There
is no
reason why the contest robot can't provide _meaningful_ feedback to
the user
such as number of QSOs (perhaps per band/mode), number of multipliers
claimed,
total claimed score, operating time (if important), operators and
call signs
used, and any other information critical to a successful entry. If
there was
a problem processing the log, I would like to know about it BEFORE the
contest results come out {grin}.
The RSGB IOTA contest submission process goes a long way towards this.
They have a multi-step process for log submission including some
feedback
steps. As part of the process for my submission this year I received a
mail message from the RSGB robot that had the following:
This email was generated automatically by the log robot.
+---------------------------------------------------------------+
Callsign used: NE1RD/1
Total QSOs (including dupes): 102
+---------------------------------------------------------------+
------------
CORRECT? [ALL OK?]
------------
If the details above are CORRECT, please visit [GO TO WWW:]
http://208.100.12.200/~iotacont/contest/iota/2006/activate/b...
and COMPLETE/ACTIVATE your log submission
The RSGB has done a great job. I am _very_ impressed with their system.
There was a lot of work to set up the software to do all this. The RSGB
invested lots of time and programming effort to make this process smooth
and effective. How many state QSO party organizers have these kind of
resources available? The answer is at best few, and probably none.
My point in this (long) message is this: it isn't just the format of
the log file; it is the whole _process_ of how submissions are handled
that should be examined if you wanted to make a wholesale improvement
to the system.
My 2-cents. Refunds upon request.
-- Scott (NE1RD)
B. Scott Andersen | "Magic is real, unless declared integer."
bsandersen@mac.com | -- The collected sayings of Wiz Zumwalt
Acton, MA (NE1RD) | http://homepage.mac.com/bsandersen
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|