I had the same thing happen on several occasions over the weekend. Also
One of the 12 computers would go down for some reason and when it came back
up the numbers changed on several bands/computers.
We went from 3 to 750+ serial number on 160 and 300+ on 80 to the same 750+
number at one time. Fought it using the -py5eg switch for a half an hour or
so and figured we would just let it go. Let the numbers fall where they may.
Good news is that we had our main compatition wondering how we increased the
numbers so quickly!!
No way to fix the way it is. Dont want to, as we gave out the numbers the
way the computers tracked them..
Maybe next year....
----- Original Message -----
From: David Robbins <email@example.com>
To: reflector ct-user <firstname.lastname@example.org>; k1ea <email@example.com>
Sent: Sunday, May 28, 2000 4:28 PM
Subject: [ct-user] screwy serial number problem
> running ct 9.50.... now follow me if you can... 6 station m/m, only one
> computer per station, only one station per band. running on 15 and 20m.
> looses radio communication to ft-1000mp for some reason and thinks its on
> but takes its serial number with it so now the 20m station gets the next
> serial number. reboot the 15m computer and it happily goes back to 15m
> keeps running, reboot 20m, it still has the 15m serial number stuck as its
> try a few things... b2r9/r2b9 corrupts the file so it won't load. (yes,
> latest version freshly downloaded from the web page)
> go in with ms visual studio and edit the binary for the 20m station, but
> think that it won't work either unless i do it on all the other stations
> the backbone now seems to be filled with each station sending what it
> next serial number is for every band... so as soon as it comes back up it
> the next number from the network and we are back where we started. go to
> and back up to edit the bad qso, move it to 160m.. now 40, 80, and 160m
> that number as the next s/n... go wrong way to put it back and hit 10m...
> all stations think the 15m number is their next number!
> temporary solution... stop all machines and reload log without the
> to 20m qso that got the bad serial number on ALL machines and move it to
> restart all machines back on the network. now 5 of the 6 are right and
> qso is on 160m... who now wants to send the next 15m number, but we don't
> about that band now anyway.
> the question is... how is one supposed to fix a sent serial number in ct
> they are stored in the bin file, but b2r9/r2b9 doesn't work, and doesn't
> show the offending serial number in the res file anyway. i can edit the
> but there must be a better way.
> David Robbins K1TTT (ex KY1H)
> firstname.lastname@example.org or email@example.com
> Submissions: firstname.lastname@example.org
> Administrative requests: ct-user-REQUEST@contesting.com
> WWW: http://www.k1ea.com/
> Questions: email@example.com
Administrative requests: ct-user-REQUEST@contesting.com