Chris' observations are correct. However this is not the long term
solution, because of some errors which I recently found in 10.56 code.
Many readers might not be interested in this explanation behind this. For
those of you who are, read on.
Prior to 10.56, each QSO in the .QDF file looked like this:
(1) ddddfffftcccccccccccciiiiiiiiiiillll--##
dddd: 32 bit number representing date/time
ffff: 32 bit number representing freq/mode
t: single byte representing transmiter nr, run/mult, xmtr1/xmtr,
main/alt radio, etc.
cccccccccccc: twelve character callsign of station worked
xxxxxxxxxxx: eleven character exchange
llll: four character location
--: unused
##: 16 bit sent serial number
This format has proven to be pretty robust. Since 1992, the only
fundamental addition has been the 16-bit sent serial number. The eleven
character exchange field is where most of the contest-to-contest variation
comes in.
When IOTA support was added in 1997 (if I recall) we needed a five
character location field. For the IOTA contest only, we "stole" the last
character of the exchange field so the format looked like this:
(2) ddddfffftcccccccccccciiiiiiiiiilllll--##
Then the NE QSO Party came along, and we again needed a five character
location field. At the same time, there had been occasional complaining
that NA's IARU support only allowed four characters for the HQ abbreviation
so it seemed like a good idea to find a more general solution.
In implementing (2), it may not be obvious but the location field "grows"
from the last character forward if the field length increases from four to
six characters. The exchange field therefore shrinks. After some
re-consideration, we decided that this was not the best approach,
particularly for third parties trying to write routines to import .QDF
files into their general logging programs (although the acceptance of the
ADIF and Cabrillo formats mitigates this somewhat).
Since the two unused characters (show as '--' in the format examples above)
has not found a useful purpose in the ten years the .QDF format has been
around, we decided to permanently add those to the location field, so the
format is now:
(3) ddddfffftcccccccccccciiiiiiiiiiillllll##
In implementing format (3) we overlooked a couple of lines of code so that
what actually is implemented is format (2). When Chris adjusted the field
length in the template file, 10.56 was reading the old IOTA file correctly.
10.57 (soon to be released) implements format (3) so Chris will be messed
up when he gets the new version. While this is regrettable, the good news
is that IARU files, old or new, will read correctly on all NA versions.
When 10.57 comes out it will include a utility called FIELDFIX.EXE which
moves the location field one character to the right. Everything will be
correct for the future.
Again, all of this only affects contests which have location fields longer
than four characters. So far this means IOTA and NEQP. I can guarantee
that 10.57 will be released in the very near future, so people should avoid
using 10.56 for IARU or IOTA (any other upcoming contests would be OK).
73,
Dave/K8CC
"G3SJJ"
<g3sjj@btinternet To: "UK-Contest"
<uk-contest@contesting.com>, <na-user@contesting.com>
.com> cc:
Sent by: Subject: [NA-User] IOTA Contest
and NA
na-user-admin@con
testing.com
06/04/2002 11:41
AM
Seem to recall Chris GM3WOJ commenting that NA Contest logger won't now
accept 5 digit IOTA refs. I was just doing some setup tests and true enough
loading my 2001 log in to v10.56, it only has a 4 digit field so EU005
comes up as U005. All is not lost, TE.EXE v 1.14 now allows you to choose
between a 4, 5 and 6 digit location. Select 5 and re-run the program.
Bingo, up comes the full EU005 etc. Nice one.
73 Chris G3SJJ
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
_______________________________________________
NA-User mailing list
NA-User@contesting.com
http://lists.contesting.com/mailman/listinfo/na-user
|