Just my two cents guys:<br><br>Instead of freezing GUI's, reserving numbers that never get used (and confuse the subsequent station that hears there is a jump in serial number), or perhaps the hardware interlock cutting of the keyboard of the other station (!!) why not then,<br>
<br>ask CQWW to restore numbering per station, and not numbering per band as it occurred after the last rule change? CQWW is using sophisticated statistic tools to find cheaters, that can easily handle multiple serial number sequences per band.<br>
<br>73, Nick<br><br><div class="gmail_quote">On Tue, May 29, 2012 at 4:30 AM, Mark Bailey <span dir="ltr"><<a href="mailto:kd4d@comcast.net" target="_blank">kd4d@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
On 5/28/2012 10:19 PM, Bob Wilson, N6TV wrote:
<blockquote type="cite">
<div class="gmail_quote">On Mon, May 28, 2012 at 7:04 PM, Mark
Bailey <span dir="ltr"><<a href="mailto:kd4d@comcast.net" target="_blank">kd4d@comcast.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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!</blockquote>
<div><br>
</div>
I agree, at high speed, constantly watching and editing the sent
serial number <i>would</i> get cumbersome.
<div><br>
</div>
<div>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." .</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br clear="all">
73,</div>
<div>Bob, N6TV</div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote></div></div>
Hi Bob:<br>
<br>
We're doing this at high rates for long periods of time.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Displaying a changing number is a particular problem in SSB -
depending on what instant the operator reads the number verses when
<br>
<br>
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.<br>
<br>
There is no perfect solution but I dislike "cumbersome". :-)<br>
<br>
73,<br>
<br>
Mark<br>
<br>
<br>
</div>
<br>_______________________________________________<br>
Support mailing list<br>
<a href="mailto:support@win-test.com">support@win-test.com</a><br>
<a href="http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support" target="_blank">http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support</a><br>
<br></blockquote></div><br>