WriteLog
[Top] [All Lists]

[WriteLog] 2R serial number question

To: <writelog@contesting.com>
Subject: [WriteLog] 2R serial number question
From: w5xd@writelog.com (W. Wright, W5XD)
Date: Mon, 7 Aug 2000 00:36:36 -0000
My previous posting on this topic, while accurate, was less than
helpful. Let me try again.

W2UP says:
*****
If the serial numbers were not 
assigned until the F-key to send the exchange is pushed, we 
wouldn't have any of these out-of-sequence/duplicate/missing 
serial numbers.
***** 

That would be true if:
1) you never abandoned a QSO after typing the F key
2) you didn't run a multi-PC network
3) you never send a serial number without an F key (e.g. SSB)

The basic problem is that if you start QSO number n, and then
start QSO number n+1, but then QSO n never gets QSL'd, then 
there's going to be a gap or duplicate number. There's no way 
to avoid that.

The network is a problem because, while it
could be done, I am at least for now, declining to implement 
any code that would pre-allocate serial numbers over the 
network. The reason for my reluctance is that there would have
to be a central "keeper-of-the-next-serial-number" on the 
network, and each PC on the network would have to check out a 
number from it during each QSO. Right now, any PC on the network
can make transmissions and log QSOs any time it wants to. It 
tells the others after its over, and the others only use that 
info for duping. You might think WL's existing network single-
transmitter lockout function already does this. It doesn't.
Each PC sends a message to all other PCs when it starts and
ends each transmission. WL does not actually stop two PCs
from going keydown at once. A PC is locked out during
the time it knows another is transmitting, but if two go
keydown simultaneously, both start. Later (milliseconds
later) WL notices from network messages it has allowed two 
transmissions and has a fixed  way of choosing which was 
wrongly allowed to transmit (the  one with the higher network 
letter) and aborts the  transmission after it started. I don't
see any way to do something similar for serial numbers.

My main reason for defending the existing serial number scheme
is that no matter what WL does, there are going to be gaps or
duplicates in the log. I admit that if WL allocated the serial
 numbers a little differently, I could reduce the numbers of 
gaps or duplicates. But I just don't see the point of working 
on reducing them when I know that they won't go away.

Barry's suggestion to allocate the numbers when the F key is
pressed is a good one--it would reduce the number of duplicate
serial numbers in the final log--but the difficulty of making
the program behave consistently among all the modes has stopped
me.

Another way to reduce, but not eliminate, gaps and duplicates
would be for WL to allocate numbers a bit differently in a 
single-PC/two-radio situation like WA9ALS mentioned. When
you have two QSOs in progress on a single PC, WL currently
sends the same serial number on both PCs. A lot of users 
are finding this annoying. I can make it send a different
number on those two simultaneous QSOs. But then, when
a QSO never gets logged, there still will be a gap and
a duplicate. I am looking at trying to get such a (simple)
mod into 10.19. But I won't call it a bug fix. Its just
an "annoyance reducer". The "bug"--gaps and duplicates--will
remain.

Wayne, W5XD

--
WWW:                      http://www.writelog.com/
Submissions:              writelog@contesting.com
Administrative requests:  writelog-REQUEST@contesting.com
Problems:                 owner-writelog@contesting.com


<Prev in Thread] Current Thread [Next in Thread>