Being a software developer myself I can easily understand how Dave
feels and thinks right now. He's convinced that there's no way his
software can make this mistake. And if I'd tested the NA software
before a contest and used it only in the most cosmetic of
circumstances I'd be in total agreement with Dave right now. But I've
now used NA and CT in multioperator and single operator circumstances
over a decade and I'll still stand by my statement. At W6EEN I've
done multioperator phone contests where a QSO number was send
"manually" by vocal chords with the two operators on the two bands
were touching elbows and there were still unrecoverable errors in
sending the proper numbers that could not be written off as operator
errors.
Dave, you should have been at W6EEN when we fired up NA 10.x for the
phone SS two years ago for 9 QSOs before we discovered that QSOs
logged on one of the two computers were being completely forgotten,
leaving only the QSOs from the other rig in the log. We had to take a
half hour break in the first hour of the phone SS to load older
versions of NA to fix that. 4-5 guys are not in our log, even though
we clearly contacted them.
I've never been at a multioperator (networked) contest where there
weren't about 50 reboots of the computers.
Here's a scenario:
Rig #1 transmits CQSS W6UE (off) (Rig #2 finds K8CC CQing)
Rig #2 transmits K8CC de W6UE (off) (Rig #1 listens, hears K0RF
calling him)
Rig #1 transmits K0RF nr1MW6UE22LAX (off) (Rig #2 listens, hears "W6UE
nr1MK8CC64MI")
Rig #2 transmits K8CC nr1MW6UE22LAX (insert key!) (Rig #1 hears "W6UE
nr4MK0RF62CO")
Both rigs log exchanges and press enter. One of the two QSO's goes
into the QSO#2 slot.
In multioperator situations it's impossible for the operators to know
which one of them has to send QSO #2 and which one of them has to send
QSO #1. They only know that the octopus lets them transmit. Without
the QSO# +/- 1 log checking rule one of the two first contacts will be
deducted from someone's log, and it wouldn't be W6UE's loss.
I hear a lot of guys with experience in antiseptic operating
environments talking about this issue as if it weren't their problem.
The trouble is that the receiving station is in danger of loosing a
contact whenever the transmitting station sends the wrong info. I'm
sure that log checkers like Tree came up with the "QSO number +/- 1"
rule after the hard experience of putting their own logs through
automated log checking only to learn that a high percentage of
stations send the wrong contact number.
The "QSO number +/- 1" version of log checking rules was under attack,
and I'm willing to defend the practice. That, after all, is what I'm
writing about. I'm not attacking the software vendors.
----- Original Message -----
From: "David A. Pruett" <k8cc@comcast.net>
To: "Leigh S. Jones" <kr6x@kr6x.com>; <cq-contest@contesting.com>
Sent: Thursday, November 14, 2002 9:46 AM
Subject: Re: [CQ-Contest] SS CW thoughts
> At 06:16 PM 11/13/02 -0800, Leigh S. Jones wrote:
> >I'm going to have to disagree with Mark here. Both CT and NA are
> >notorious for sending the wrong QSO number by 1.
>
> I don't think this is a fair characterization at all. I will not
speak for
> CT or TR, but with NA there is a clear, definite logic as to the
serial
> number sent:
>
> THE SERIAL NUMBER SENT IS ALWAYS THE NUMBER OF THE QSO THE CURSOR IS
ON
>
> The problem comes when you've logged the QSO, and the station at the
other
> end wants a repeat. The correct way to do this is to MOVE BACK TO
THAT QSO
> AND PRESS THE KEY TO SEND THE EXCHANGE. However, some users don't
do that
> - they just press the key (on the blank QSO line, since they just
logged
> the QSO they are repeating) and hence send one higher than the
number they
> should.
>
> The answer to this, some will say, is that if the line is blank the
> previous number should be sent. This will correct the described
condition,
> but creates another.
>
> Suppose you QRZ, and somebody dumps the call back fast and you can't
get it
> entered; you send the call on the paddle then press the key to send
the
> exchange. To use another example from WPX or most any contest other
than
> SS with serial numbers: you dump your call in a pileup, but you
don't know
> the other station's call yet; he sends the exchange, you hit the key
to
> reply with your exchange; on his QRZ you get his call and log the
QSO.
>
> Many years ago NA used to "send the previous number on a blank
line", but
> we found it to be a problem. The "always send the number the cursor
is on"
> is certain, and experience has proven it to be less troublesome.
Other,
> "fuzzy logic" algorithms which guess at which the operator intends
creates
> uncertainty and, I would argue, more errors.
>
> My reason for using the bandwidth for this explanation is to make
the point
> that NA (or CT or TR) are not *notorious* for sending wrong numbers.
As
> long as a certain set of keystrokes produces the correct result, the
fault
> is operator error. One can argue that a particular set of
keystrokes might
> not be "user friendly", but that is a different discussion.
>
> Dave/K8CC
>
|