<div class="gmail_quote">On Mon, May 28, 2012 at 3:34 PM, Rick Dougherty NQ4I <span dir="ltr"><<a href="mailto:nq4i@contesting.com" target="_blank">nq4i@contesting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Hi All...used WT in WPX CW and it worked really good...it does however have a major issue...when it comes to numbers sent and numbers in the que it does not do the job.</div><div> In a Multi Multi when both stations are very active..its the toss of the dice to see who gets what number...the RUN station send a number only to find out that the MULT station has already given the number to another..and it will send the WRONG number to the RUN stations qso...one of my ops figured out a work around..he would immediately log just the number 1 in the logging field, use INSERT to send the exchange, and then backspace the 1 out of the logging field and insert the correct call in...thats too much work for a RUN op....A premier logging program needs to be a leader in the field...WT is one of the premier logging programs on the market and the choice of many M-M's, M-2's, and M-S stations..it is time to </div>


<div>step up to the plate and fix the problem.....some sore of fix is needed...I am hoping that by the time we do WPX next year that this is not an issue...</div><div> </div><div>Thank You</div><div> </div><div>de Rick NQ4I</div>

</blockquote><div><br></div><div>To review, NQ4I is a multi-multi station with both RUN and MULT stations operating and interleaving QSOs on a single band.  Serial numbers are sequential by band.</div><div><br></div><div>

The problem of serial number "reservation" is unique to this situation, and it is a problem more difficult to solve technically than you might think, especially with many networked computers and some critical timing issues.  N1MM logger does it one way, but as a side effect, it occasionally leaves gaps in the serial number sequences, causing a bit of inflation in the QSO numbers being sent (as some serial numbers are reserved but never sent).</div>

<div><br></div><div>I don't understand how quickly entering a "1" in the no. received field solves this issue.  It seems like it is still possible for both stations to send one serial no. but log another.  I thought whoever hits "Enter" first causes the serial number to immediately incremented across all computers in the network.</div>

<div><br></div><div>I think the easiest way to work around this problem in Win-Test is to simply provide a better method than the cumbersome "Edit | Edit sent serial no." dialog, so that you can quickly change the QSO no. logged to the QSO no. that was actually sent, whenever a timing glitch causes them not to match.</div>

<div><br></div><div>Note that it is perfectly acceptable to send the exact same serial no. to two different stations, one by the RUN, one by the MULT.  There is no requirement that serial numbers sent be 100% unique, as long as the number logged in the "sent" column of the log and the Cabrillo file precisely matches what was sent to the station on the other side.</div>

<div><br></div><div>You can currently use the "<" and ">" keys (Shift+comma, Shift+period) to move the cursor to <i>any</i> field in the logging window, even the TIME column, but <i>not </i>the sent serial no. column.</div>

<div><br></div><div>If you could just edit the SENT serial no. column as easily as you can edit the RST SENT column, this problem wouldn't be very cumbersome to deal with.  There would be no problem if you sent the same serial no. to two stations, just fix the log to indicate that.  At least this fix, though not ideal, is more likely to be implemented than a much more complex synchronized serial no. reservation system that would otherwise be required.</div>

<div><br></div><div>73,</div><div>Bob, N6TV</div></div>