What's wrong with the CW operator sending CW now & then to manually correct
repeats? That way, the number sequence is never impacted. After all, we
are not robots.....or, are we?
----- 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 10: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
>
>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>
|