I have been trying to import contest logs from CT to DXLog and now to DX4WIN
for over 11 years and constantly have problems. It seems CT authors keep
changing routines without notifying the users and the authors of the various
logging programs, such as DXLog and DX4WIN. The most recent and nagging
problem has been repeating itself over several years regarding specifically
the CQ WW Phone contest held over the same weekend that we change from
Eastern Daylight Savings Time to Eastern Standard Time. I am not sure this
is the cause, but it seems very coincidental.
For example, when I imported the CT log for CQ WW Phone Contest of Oct. 30
and 31, 1999, the B2R9 program provided by CT converted the times for every
QSO on Oct. 30 to one hour earlier, but the times for all Oct. 31 QSOs were
left alone and correct! I had the same results using B2R9 versions dated
10/28/98, 2/1/98, and 4/22/94. I tried B2R9 version dated 1/25/99 and the
times for each QSO on Oct. 30 and Oct 31 were moved up by 5 hours, which by
coincidence is the difference between UTC and EST. But even that does not
make sense, because EST does not apply to Oct. 30, even if I were using
local time in my computers, CT, DX4WIN, and DXLog. I repeat that I use UTC
for all logging and ham computers.
I really first started noticing this problems several years ago when I
received many QSLs for CQ WW Phone contest QSOs which had times differing
from my logs by one hour. At first I thought I made errors, or perhaps many
other contesters did not know their correct times. But now I find that is
in the import routine.
The authors of DXLog and DX4WIN have both told me that the problem lays at
the CT door, since they write B2R which DXLog and DX4WIN use for importing.
Did anyone else have this problem? Is there a better version of B2R9 out
there which has a fix? I downloaded the last version of B2R9 from
www.contesting.com/ctvault today and it had no improvement. I was hopeful
since the note next to this release of B2R9 said "time fix".
Look at your converted CT logs (CT file.RES) and you will see the one hour
jump back from 0057Z Oct. 31, 1999 in CT.BIN to 2357Z Oct. 30, 1999 in
CT.RES. The next QSO at say 0100Z Oct 31, 1999 will have the same time and
date in CT.BIN and the CT.RES file and the imported logs.
As an aside, I also ran into time problems in one contest where I tried
running CT-9.30 on two computers and CT-9.42 or CT-9.45 on two other
computers, all CT loop networked. They were not compatible. The times
logged were all messed up on the computers. Soon as I could stop each
computer, I switch all four back to CT-9.30 and the problem stopped. But I
had to edit and correct every entry in all four computers for prior QSOs.
The reason we had different versions in use was because CT-9.30 has been
quite reliable on iCOM, Kenwood, and Yaesu radio interfaces. But CT-9.42
and CT-9.45 crash with iCOM radios. So we had two iCOMs, one Kenwood, and
one Yaesu. We had the crashes just before the contest, so did not have time
or desire to switch all four quickly back to CT-9.30. We paid the price
during the contest stopping runs to fix each computer. Now we shall stay
with CT-9.30 until a STABLE version of CT 9 emerges and is proof tested.
This again is an example where the CT authors are tinkering with the time
keeping in CT without telling us.
--
Submissions: ct-user@contesting.com
Administrative requests: ct-user-REQUEST@contesting.com
WWW: http://www.k1ea.com/
Questions: owner-ct-user@contesting.com
|