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
|