Hi Mike,
yes, you are right, but
for Cabrillo:
what if the logging SW does not follow this specification. What if it uses some
self-defined tags? What if you can get these versions of Cabrillo standard
depending on type and version of SW which was used by the entrant to generate
the cabrillo log:
QSO: 7000 CW 2005-11-12 0001 K1ABC 599 001 OK1ABC 599 APA
QSO: 7000 CW 2005-11-12 0001 K1ABC OK1ABC 599 599 APA
QSO: 7000 CW 2005-11-12 0001 K1ABC OK1ABC 599 599 APA OK1
QSO: 7000 CW 2005-11-12 0001 K1ABC OK1ABC 599 599 APA 1
QSO: 7000 CW 2005-11-12 0001 K1ABC OK1ABC 599 599 APA 1 OK1
QSO: 7000 CW 2005-11-12 0001 K1ABC OK1ABC 599 599 APA OK1 1
QSO: 7000 CW 2005-11-12 0001 OK1ABC 599 599 APA
QSO: 7000 CW 2005-11-12 0001 K1ABC 599 001 OK1ABC 599 APA OK1 1 0
QSO: 7000 CW 2005-11-12 0001 K1ABC 599 001 OK1ABC 599 APA OK1
QSO: 7000 CW 2005-11-12 0001 K1ABC 599 001 OK1ABC 599 APA 1
Please note we have a definition of cabrillo template on our web page. See
http://okomdx.crk.cz/cab.html.
Sorry, but I do not call it the STANDARD.
One of the reasons of this situation in my point of view is lack of standard
procedure how to put the template for a contest into cabrillo spec web page so
the contest logging writers can see it there and implement it into their SW.
But also the contest organizers have to care about it. It is not enough to say
"cabrillo log welcomed" in their contest rules, they have also say how their
cabrillo should look. Especially when their contest exchange contains more
items, not only serial number for example.
and for ADIF? The main problem is what tag should contain contest exchange.
Although AFAIK there is a specification for it in ADIF specification, there are
many ways how the different logging programs are doing it. There were at least
3 or 4 different tags used depending on SW and its version which was used to
generate the ADIF file. BTW there are also situations where length of the
content of a tag does not agree with length specified within tag definition
area. So to handle an ADIF log is generally not a problem, but it is problem to
understand which field contains needed information.
By native log format I mean for example *.DAT file for TRLog, *.ALL file for CT
etc.
Zdenek
OK1DSZ
> ------------ Původní zpráva ------------
> Od: Mike <nf4l@nf4l.com>
> Předmět: Re: [CQ-Contest] A Plea to Cabrillo Contet Robot Writers
> Datum: 13.1.2007 17:32:36
> ----------------------------------------
> Zdenek Sebek wrote:
> > I will not comment internal format of Cabrillo, because it would be too
> > long.
> I will write only this. AFAIK the main reason why the Cabrillo has been born
> is
> to have a logfile format which it would be easy to import into the log
> checking
> systems. I have seen many cabrillo files produced by many contest logging
> programs and different versions of these programs. A have also written parsers
> for native logs from CT, TRLog, SD, ADIF and some more. From this experience I
> have learned it is MUCH EASIER to write a ROBUST parser any native log format
> than for the Cabrillo. And in general it is even easier (or at least not more
> difficult) to maintain several parsers for native log formats than one for
> Cabrillo. Please note word ROBUST, which means the parser is able to process
> succesfully many different versions of Cabrillo STANDARD logs. And for those
> suggesting to use ADIF - to parse an ADIF is even worse.
> >
> Huh? All you have to do is read it in, and look for the tags. MUCH
> simpler. And more ROBUST. Same for XML. What do you mean by
> native log format ?
> 73, Mike NF4L
>
>
>
>
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|