Ed,
Yes, you can only have either serial numbers or frequency info in a given
LOG.DAT file. However, with the help of POST, you can create two log files
for the same contest, one with serial numbers (lallboth.dat) and one with
frequency info (log.dat). And since the Cabrillo format has room for both
(in contests where serial numbers are exchanged), you can have both in a
single Cabrillo file. As I see it, the current discussion has been mostly
about how to produce such a maximum-info Cabrillo file, even if only because
such a file is more intellectually or esthetically satisfying than one with
meaningless info (i.e. the extra zeros) in it!
I use LOG FREQUENCY ENABLE = TRUE all the time. The only down side I have
thought of to this practice is that if you ever manage to get the sent
serial number out of kilter, the reconstituted serial numbers generated by
POST will not be the same as the ones you sent. Offhand, the only way I can
see to do this is to edit contacts into or out of LOG.DAT before doing the
POST /L /C step, but I suppose there might be other ways, especially in
multi-radio or multi-computer setups.
However, in response to Mike's comment, I am not sure how much help
frequencies would actually be in log checking. After all, the rules don't
require you to report frequency information. Is the log checking software
going to look for frequency matches as well as call sign, time and exchange?
If you were DQed because of out-of-band QSOs, some of us might consider that
that was only fair, but how would you feel if you lost credit for some QSOs
because the frequency in your log didn't match the frequency in the other
guy's log?
Anyway, my guess is that frequency data would be most useful for manual
checking of cases the log checking software couldn't resolve unambiguously.
In the end, only the log checkers can tell us whether frequency info would
be useful enough for them to encourage the rest of us to report it.
Otherwise, I think it is simply one of those "nice to have" features - if
brand W or brand M software does it, why not brand T?
73,
Rich VE3IAY
----- Original Message -----
From: "J. Edward (Ed) Muns" <w0yk@msn.com>
To: "Mike Gilmer, N2MG" <n2mg@eham.net>
Cc: "Richard Ferch" <ve3iay@rac.ca>; <trlog@contesting.com>;
<tree@contesting.com>; <kk1l@arrl.net>
Sent: Tuesday, November 26, 2002 3:30 PM
Subject: RE: [TRLog] Cabrillo file frequency info
> I may be wrong, but my understanding is that you can choose to have EITHER
a
> QSO number OR the frequency. I really wanted the frequency record as
well,
> but didn't want to give up the QSO number, so I left LOG FREQUENCY ENABLE
=
> FALSE deliberately. I haven't tested my "understanding", which could be
> wrong.
>
> 73,
> Ed - W0YK
>
> > -----Original Message-----
> > From: trlog-admin@contesting.com [mailto:trlog-admin@contesting.com]On
> > Behalf Of Mike Gilmer, N2MG
> > Sent: Tuesday, November 26, 2002 11:21 AM
> > To: Richard Ferch; trlog@contesting.com
> > Cc: tree@contesting.com.kk1l@arrl.net
> > Subject: Re: [TRLog] Cabrillo file frequency info
> >
> >
> > > First, is the frequency info in your log.dat file? i.e., did you
> > > use LOG FREQUENCY ENABLE = TRUE in your config file? If not, the
> > > frequency information is lost forever.
> >
> > Indeed...no I did not set this to TRUE. Unless someone can tell me why
> > it would be a bad thing, I hereby, respectfully, suggest that TR
> > default to having this set to TRUE. I believe that in the current
> > environment of leg checking (and Tree's strong relationship
> > with it) that having logs default to missing this data is a real
> > shortcoming. Of course, for this to make sense, this means that the
> > CBR output must also include this data.
> >
> > 73 Mike N2MG
> > _______________________________________________
> > TRLog mailing list
> > TRLog@contesting.com
> > http://lists.contesting.com/mailman/listinfo/trlog
> >
>
>
|