Just awoken from last night's WPX, we had almost had the same problem
as K1TTT at SK0X, although its origin was different. We were also
running a 6 stn network with a M/M operation. At a certain point and I
don't know the exact reason, our 15 mtr stn got the serial # of its
last QSO wrong. I suspect that inadvertently (Alt-F2) that computer
was moved to 20, one qso was logged on that band, and the opr moved
the band back to 15. Then, he was stuck with the wrong # as the last
serial sent (in memory and it seems that CT maintains it for each band
in the .BIN file), even though he tried moving the band around again.
20 mtrs had the highest QSO #, if that matters, and this computer was
master in the daisy chain.
This spread to other bands, a re-boot of all computers at one time
corrected the serial on 15, but the synchronization process put
everything happily wrongly back to the 20 mtr # on all bands. No
workaround available, since the serial is not accessible from
anywhere. Finally (we didn't have the tool for binary editing that
K1TTT mentions!), we settled for sending the 'new' serials with a
break in the progressive series.
Obviously, this is a show-stopper. One or two suggestions:
- A 'SETSERIAL' command, which corrects it on the band of the command
line.
- A way to correct older qsos with incorrect serials. Possibly the Tab
key could tab to the serial # field, too. Cannot POSTCONTEST mode
activate all fields, including the time?
73,
Goran, SM0DRD
--
Submissions: ct-user@contesting.com
Administrative requests: ct-user-REQUEST@contesting.com
WWW: http://www.k1ea.com/
Questions: owner-ct-user@contesting.com
|