Whoa.... copying log.dat from one computer to another is a VERY bad idea
unless EVERY QSO was logged correctly without any editing (in the editable
window or at least before they are sent to the network). Each computer
contains data for all the stations - only the actual QSOs made using that
computer should be considered correct. Edits are not passed along the
Here, if we need to sync the numbers one enters a dummy QSO (your own call
or something safe) on the lagging computer and then ALT Y's it from the
other computer(s). Obviously if the other computers are busy making QSO's
at the same time it is a distraction.
On Sat, 4 Dec 1999, Igor Sokolov wrote:
> First check your MULTI RETRY TIME and set it to minimum
> Then we had the problem of serial number getting out of sinc for a long
> time. The cure use to be copying log.dat from the correct computer to
> another one using floppy.
> Now we have a network in place. We could as well transfer the correct
> log.dat via network similar to Alt-T command setting clock on all of the
> networked computers. I hope that one day Tree will implement this or even
> some better feature. In the mean while just keep a floppy handy.
> Igor, UA9CDC
> -----Èñõîäíîå ñîîáùåíèå-----
> Îò: Mike Heideman <firstname.lastname@example.org>
> Êîìó: email@example.com <firstname.lastname@example.org>
> Äàòà: 3 äåêàáðÿ 1999 ã. 22:46
> Òåìà: [TRLog] Sequence number problems
> :We've now used TR Log for 5 contests here at W6YX (CQP and both modes SS
> :CQWW) and have encountered sequence numbering problems in every contest.
> :have a 486 interfaced to an IC761 set up for keying on CW and no radio
> :control. This is networked to a laptop 486 that has no radio interface at
> :all (yet). Here is our config file for the interfaced computer:
> :MY CALL = W6YX
> :CONTEST = SWEEPSTAKES
> :DISPLAY MODE = COLOR
> :KEYER RADIO ONE OUTPUT PORT = PARALLEL 1
> :PADDLE PORT = 1
> :MULTI PORT = SERIAL 1
> :COMPUTER ID = A
> :The other computer has no PADDLE or KEYER PORT config and is set up as ID =
> :B. Both computers were booted up in DOS (I'm not sure what versions).
> :The symptom that we see is that a QSO is occasionally not transmitted from
> :one computer to the other. In CW SS this occurred once in 1058 QSOs. In
> :Phone SS it occurred 3 times in 1741 QSOs, alternating between computers,
> :that the sequence numbers were resynchronized after the second transmission
> :loss, but got out of sync again later. This is a real nuisance because we
> :have to remember to send a number one higher than is displayed on the
> :lagging computer. It also caused us to send the same sequence number to
> :stations before we realized it. Our rate was slowed down by an occasional
> :"Oops, sorry, you should have been number 'N+1'".
> :After CW SS we assumed the problem was caused by frequent editing with
> :ALT-E. During Phone SS we didn't use ALT-E at all, instead noting all
> :corrections with notes. It still happened. I had to merge the CQWW logs
> :from the two computers for both Phone and CW because one or two contacts
> :hadn't transferred to the other computer.
> :Is there a configuration setting that can be changed to prevent this from
> :happening? Is there a way to ensure that all QSOs are transferred between
> :computers? I would think that for a contest where a single serial number
> :has to be shared between computers this could be more easily enforced. If
> :the program can't do it automatically, then perhaps there should be a
> :way of forcing synchronization.
> :I've been busy at work lately so I haven't had a chance to go to the shack
> :to test any theories about how the QSO transmission fails. One or two of
> :the failures seemed to coincide with a time when the (non-)receiving
> :computer was being used for composing or posting a note.
> :Other than the sequencing problem, we've only encountered a small number of
> :annoying behaviors:
> :1. Correction of a callsign or band using ALT-E doesn't adjust the
> :multiplier status of the station. We had worked 6V6U very early on 20M in
> :CQWW CW, but our operator thought he'd worked B4BU (don't ask me why...)
> :then corrected the call. Later in the contest I noticed that the
> :list showed we hadn't worked 6W on 20, so I didn't even try duping the call
> :when I heard him. After 5 minutes in the pileup and major disruption to
> :CQing station, I finally got him only to have him say we were a dupe.
> :Ensuring that a station is a new multiplier on a band is crucial for
> :multi-single stations in CQWW. In the phone contest we accidentally worked
> :two stations that weren't new multipliers from our multiplier station
> :because they were accidentally logged as 15M and edited to 10M later (I
> :can't wait to interface the radios...)
> :2. We ended up logging several dupes in the Phone SS because we used the
> :CALLSIGN UPDATE ENABLE feature and edited callsigns in the exchange window.
> :We didn't find out they were dupes until after hitting return and seeing
> :in the points column. Is there a way of preventing the logging of such
> :dupes? I noticed that editing in the callsign window after the exchange
> :been copied also causes a dupe to be logged.
> :3. When I tried interfacing our FT1000MP, it was in a slow tuning mode so
> :took about 10 seconds to move 1 kHz using the shift keys. I held down one
> :of the shift keys for about 5 seconds, tuning, and when I let go of it the
> :radio continued to drift. Finally after about 5 minutes I rebooted the
> :computer to stop it. I'm glad this didn't happen in the middle of a
> :4. The one new feature that I would greatly appreciate is the ability to
> :have ALT-E edits propagate to other computers on the network. For a
> :multi-single, two-radio station with one interfaced radio, both radios tend
> :to be used on all bands and it is important that information like corrected
> :bands/callsigns/zones get propagated to all computers to prevent rules
> :violations that put the station into the multi-multi category.
> :Overall, though, the program has worked great for us and we are learning
> :using more new features with each new contest.
> :-Mike, N7MH
> :FAQ on WWW: http://www.contesting.com/trlogfaq.html
> :Submissions: email@example.com
> :Administrative requests: trlog-REQUEST@contesting.com
> :Problems: firstname.lastname@example.org
> :Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
> FAQ on WWW: http://www.contesting.com/trlogfaq.html
> Submissions: email@example.com
> Administrative requests: trlog-REQUEST@contesting.com
> Problems: firstname.lastname@example.org
> Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
VE6JY Don Moman email: email@example.com
Box 127 Lamont, Alberta email forwarding: firstname.lastname@example.org
CANADA T0B 2R0
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Administrative requests: trlog-REQUEST@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html