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
|