: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).
We do not do editing, it does not get passed over the network. We put it
Ctrl-N note which find its way to all the other computers. Besides there is
usually a RUN station and mult station. RUN computer log is a MASTER log and
we make sure it is always correct, but in addition to that some precautions
could be done when executing COPY LOG TO NETWORK COMPUTERS command. For
instance previouse logs could be saved under different name automatically.
Anyway for the last 2 years we always did it that way and never had
problems. Sometimes network computer can HANG and you may loose last 5 qso.
Then the only way to get back to sync is to copy a correct version of
log.dat to that computer.
: 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
:network.
Just do not do edits. Do Ctrl-N.
: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.
What if you get the difference of more that 5 QSO? How do you mend that?
Igor, UA9CDC
:
:73 Don
:VE6JY
:
:
: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 <mikeh@airflash.com>
:> Êîìó: trlog@contesting.com <trlog@contesting.com>
:> Äàòà: 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
:> and
:> :CQWW) and have encountered sequence numbering problems in every contest.
:> We
:> :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,
:> so
:> :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
:> two
:> :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
:> manual
:> :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...)
:> and
:> :then corrected the call. Later in the contest I noticed that the
:> multiplier
:> :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
:> our
:> :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
:> '0'
:> :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
:> has
:> :been copied also causes a dupe to be logged.
:> :
:> :3. When I tried interfacing our FT1000MP, it was in a slow tuning mode
so
:> it
:> :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
:> :contest.
:> :
:> :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
:> and
:> :using more new features with each new contest.
:> :
:> :-Mike, N7MH
:> :
:> :
:> :--
:> :FAQ on WWW: http://www.contesting.com/trlogfaq.html
:> :Submissions: trlog@contesting.com
:> :Administrative requests: trlog-REQUEST@contesting.com
:> :Problems: owner-trlog@contesting.com
:> :Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
:> :
:> :
:>
:>
:> --
:> FAQ on WWW: http://www.contesting.com/trlogfaq.html
:> Submissions: trlog@contesting.com
:> Administrative requests: trlog-REQUEST@contesting.com
:> Problems: owner-trlog@contesting.com
:> Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
:>
:
:VE6JY Don Moman email: ve6jy@freenet.edmonton.ab.ca
:Box 127 Lamont, Alberta email forwarding: ve6jy@rac.ca
:CANADA T0B 2R0
:(780) 895-2925
:
:
:--
:FAQ on WWW: http://www.contesting.com/trlogfaq.html
:Submissions: trlog@contesting.com
:Administrative requests: trlog-REQUEST@contesting.com
:Problems: owner-trlog@contesting.com
:Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
:
:
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|