[ct-user] WPX numbering screwy

[Dan Robbins]

Another problem with CT keeping numbers straight in WPX SSB:

Part I

We were running M/M and right near the start of the contest 20m QSO #41
logged ok.  The next number on the logging line came up as 42, then
changed to 109 and stayed that way.  Entering the QSO info for what
should have been our NR 42 (SENT) resulted in NR 109 being logged.  109
was the same number as what 15m would be sending next.  We dropped the
20m computer off-line and rebooted, but the number was still wrong.  Now
numbers on the other band were getting hosed, too.  10 went from NR 129
to NR 300 and 15 went from NR 153 to 301.  80m went from NR 1 (still
daylight here so no 80m Qs yet) to NR 89.

I shut down all computers and rebooted them all - no help.  Everybody
was on the right band and everybody was showing M/M.  I was running
CT950 on the computers as it had played ok during last WPX.  I loaded
CT954 on all the computers and booted up - no help.  Then I tried going
back to CT947 and bingo, the NR came up properly on the entry line.  The
NR continued to log wrong, but at least the entry line had the correct
NR so we knew what to send.

Why this numbering glitch occurred is a mystery.  We were not
experiencing any RF problems and in the past any RF problems we have had
were related to the low bands which were not transmitting at this time.
The CT network is 486 computers with NIC cards running NETTSR and RG-58
ethernet.  Changing from serial port daisy chain to ethernet has really
helped - our network problems disappeared.  In retrospect, I noticed
that the 20m computer and the 80m computer were actually running CT951,
not CT950, I forgot I had upgraded them for SS 2000.  Could it be that
there was some conflict between CT951 and CT950?  Any suggestions on how
to prevent recurrence of this problem would be appreciated - we lost
well over a couple of hundred potential QSOs while we tried to sort out
this numbering problem.


Part II

Going back to CT947 created a bunch of other problems - the mode changed
to RTTY for example and I had to go and reprogram the initial screen to
get the mode right and get the DVPs going again.  But it gets worse.
Upon merging, the first few hundred QSOs all wound up at 0628Z Feb 6,
1906.  Hell of a rate.  I suspect there was a time screwup in going back
to CT947.  (Fortunately, I backed up the files before I did anything.)

Another problem appeared to be with the assignment of the #1 computer in
the network.  When the initial problem occurred on 20m, which is my #1,
I had to shut that computer down.  Since #1 times the whole network, I
swapped assignments so 20m became #2 and another computer became #1.
Unfortunately, the date was a day off on the new #1, which hosed up the
log even more.  I guess the moral here is you can't just set the times
correctly on all the computers before the contests - set the dates,
too!  Because a QSO showed up on different dates, the merge program
treated them as separate QSOs.  Hell of a dupe rate.

Anyway, I did a .bin to .res conversion for all 6 bands.  In the .res
files, I entered the correct times which were hosed up by the version
change.  Then I corrected the 1906 dates which were hosed up by the same
change.  Then I corrected the QSOs that were off by one day because of
the computer date being off.  Next, all the .res files went back to .bin
files.  Finally the merge gave me a final, correct log.  I had to run
Evil's CT_FIX program to get the numbers right.

Part III

Almost right.  There is a flaw in the merge program which I found.  As
an example, on 10m we might have worked JA1XX and given him NR 600.
Within the same minute we next worked JA1YY and gave him NR 601. Now
suppose there is a network problem, a downed computer or something, and
NR 600 gets logged on the 10m computer but not across the network.  But
then the network comes up and NR 601 gets logged across the network.

At the end of the contest we do a merge.  If we start at 160 and merge
up, JA1YY shows up on the 160m .bin file and gets put into the merge
file properly on 10m.  JA1XX only gets put in there at the end of the
merge process when we do the 10m .bin file.  But, apparently he gets put
in AFTER the existing JA1YY QSO.  Which is actually out of order.  JA1YY
was sent NR 601, but gets in the log as receiving NR 600.  The
discrepancy only showed for QSOs in the same minute, but I saw several
of them as I pored over the times in the log. Obviously this would have
been a bigger problem with us as we had the computers up and down a lot
during some periods of the contest, but I would not want to ever merge
an SS log where the numbers are closely checked!

Anybody who feels that it is should be mandatory to send the logs in
immediately after the contest has never spent days resurrecting a
computer log.

Doing logs should not be this hard.


Dan KL7Y




--
WWW:                      http://www.k1ea.com/
Submissions:              ct-user@contesting.com
Administrative requests:  ct-user-REQUEST@contesting.com
Problems:                 owner-ct-user@contesting.com