[CQ-Contest] SS CW thoughts

David A. Pruett k8cc at comcast.net
Thu Nov 14 12:46:26 EST 2002


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





More information about the CQ-Contest mailing list