We had problems all through the CQWWCW with serials getting out of
synch. In the end it doesn't matter, but what about the WPX...
We need a command to force the serial to a correct value on a given
computer, if the serial fix turns out to be one of those awful things.
As a matter of perspective, we only try this stuff because we have TR
in the first place, and all these features keep getting added...
On Fri, 3 Dec 1999 09:41:45 -0800, you wrote:
>
>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
--. .-..
73, Guy
Guy Olinger, K2AV
k2av@contesting.com
Apex, NC, USA
--
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
|