[WT-support] Win-Test and contest numbers

[Mark Bailey]

On 5/28/2012 10:19 PM, Bob Wilson, N6TV wrote:
> On Mon, May 28, 2012 at 7:04 PM, Mark Bailey <kd4d at comcast.net 
> <mailto:kd4d at comcast.net>> wrote:
>
>     Your proposed solution interferes with the rhythm of the run
>     operator.  And, I still think that tired operators won't do this
>     well at 5:00AM!
>
>
> I agree, at high speed, constantly watching and editing the sent 
> serial number /would/ get cumbersome.
>
> Maybe all that is needed is for Win-Test to save whatever value wast 
> last-used for the $SERIAL CW variable on each computer, and it could 
> just log that last-sent serial no., unique or not, instead of always 
> saving the constantly changing "current serial no." .
>
> But, how do we make this work just as well on phone as on CW?  How do 
> you coordinate sent serial numbers when operating multi-multi with 
> RUN/MULT on the same band, on phone?
>
> I wonder how multi-multi's did this in the old days of paper logging. 
>  Maybe that was well before the "octopus" became essential to the 
> process of competing and winning as a multi-multi in WPX.
>
> 73,
> Bob, N6TV
>
>
Hi Bob:

We're doing this at high rates for long periods of time.

I don't have a long historical perspective, but the M/M competition is 
at a higher level than it was 12 years ago!  :-)   With the RBN on CW, 
our hourly rates are much higher than they used to be on CW - due to 
interleaving QSOs.  We have to do this to stay competitive.

Just making sure the GUI didn't change as soon as the first character of 
a call is entered, and logging what is displayed, could fix part of the 
problem both in CW and SSB.  This would introduce other quirks like 
sending duplicate serial numbers, but it avoids sending something 
different than what is logged.

Displaying a changing number is a particular problem in SSB - depending 
on what instant the operator reads the number verses when

Phone needs to be the same as CW and just the normal sequence of 
running, without extra steps and without requiring coordination between 
the run and S&P operators.

There is no perfect solution but I dislike "cumbersome".  :-)

73,

Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.f5mzn.org/pipermail/support/attachments/20120528/b2eb878d/attachment.html>