On a similar note...the ZM2K log has a time problem which I have as
yet been unable to fix.
Perhaps someone who has been there has a few suggestions.
For the first part of our 40 m log QSOs were logged with the wrong
time/date...
To correct the problem, I first b2r9-converted the 40 m log to
40.res. Next I made corrections using the search/replace function of
a simple text editor, careful not to insert control codes.
The fixed 40.res log was then converted back to 40.bin using r2b9.exe
(which used the old, broken 40.bin for setup info, renaming it to
40.old afterwards).
After having merged all the different bands into one .bin, I ran up
CT and used writelog to produce a complete set of files.
The interesting thing is, that most bands now show huge numbers of
dupes. E.g. the 20 m file shows lots of QSO twice, one straight after
the other. Time/date stamps are the same, but the second QSO is
correctly flagged a dupe.
This problem doesn't occur when I use the faulty 40 m log. Aside from
the wrong date/time on the first lot of 40 m QSOs, no abnormal dupes
appear.
Any suggestions on what is happening here are appreciated. The only
avenue open to me now is to load the merged, faulty log into CT and
hand-edit the faulty 40 m QSOs using the CT time edit function :-(
Wilbert, ZL2BSJ.
PS: CT version 9.27
--
Submissions: ct-user@contesting.com
Administrative requests: ct-user-REQUEST@contesting.com
WWW: http://www.contesting.com/ct/
Questions: owner-ct-user@contesting.com
|