> I take it the official answer is a "No comment"?
Not quite. The answer is "we have been over this before". If
you consider that the alternative "better work arounds"--which
reportedly involve logging a different serial number than was
sent over the air, then you are welcome to use those. However
you might find that such alternatives actually cause log checkers
to remove credit for QSOs in your log.
I have yet to hear of even one QSO being discredited from even
one log for having a gap or out-of-order serial numbers.
There is a logical impossibility lurking behind these discussions
that I believe many commenters are overlooking. If you look
at the issue closely, you will find it impossible to do have ALL of these
at once: (a) only consectutive serial numbers without gaps and
(b) serial numbers in order, (c) no duplicate numbers
(d) have more than one QSO in progress at a time (this applies to
single op and multi-op) (d) don't log QSOs that fail to get QSLed
(e) allow networked stations to continue seamlessly standalone when a
station drops off the network
Anyone whose definition of "correct" requires all the above
is going to have to wait quite awhile before the software solution
they are seeking shows up--and if you would like to engage
in some discussions in formal logic you can prove that you will
have to wait forever.
All of this is NOT to say that WL's handling of serial numbers cannot
be improved. I suspect it can. But countless postings of "I got a
gap" or "I got a duplicate" are going to be ignored until someone gets
a QSO disqualified for doing so.
Wayne
>
> Our club was about to re-register the software as we are
> now out of date and need to pay for the upgrade again, but
> to be honest I believe we will not now. Writelog is a good
> program that appears to be upgraded continually with regard
> to the US contests and all the complicated features integrating
> it to other programs, but this is all done at the neglect to anything
> requiring functional serial numbers (Ie RSGB mainly).
>
> There was me thinking this was a support and suggestions
> forum too. Maybe we can all start pleading the 5th when it suits us?
>
> Robert
> MM0ANT
>
>
>>To: writelog <writelog@contesting.com>
To: <writelog@contesting.com>
>>Date: Sun, 26 Jan 2003 23:39:38 +0000
>>Subject: [WriteLog] Serial Numbers and IOTA (as example)
>>
>>
>>
>>I asked this last year and still do not feel an answer has come
>> forward, I only bring it up as the subject of serial numbers, and
>> fixes, seems to be making a revival.
>>
>>During IOTA as a M/M operation a lot of groups require a solid form of
>> serial number generation. At present there seems to solid way to
>> confirm you are giving out correct serial numbers. I would take it as
>> far as to say I can confirm that, in normal operation, over 30% of all
>> serial numbers issued would be incorrect (This data supplied by a
>> recent CQWW SSB entry). During tests pre-CQWW2002 I could reliably get
>> every QSO as a failed serial-dupe. Thankfully CQWW wasn't serial-number
>> based as if it was, Writelog would not have been used.
>>
>>If two users pre-type a callsign into the software and prepare for the
>> final details the software will most likely give both contacts the same
>> serial. I know a way round this has been suggested; To only start the
>> QSO logging after all data confirmed but this is
>> _seriously_unacceptable._ It is simply not possible to operate
>> competitively in this way over a 24 hour period.
>>
>>Software like NA and CT also have problems with this operation, but
>> have better work around's in my opinion. The problem with their
>> systems is the dodgy networking and cluster support requirements.
>> Writelog really rules the roost at present, yet it cannot issue serial
>> numbers for a M/M team.
>>
>>Is there likely to be a fix before IOTA? - One which will issue serial
>> numbers correctly.
>>
>>If not, Is it possible to drop serial numbers into the software via
>> your SDK set? I would be more than interested to try and find a better
>> solution if this "SDK drop-in" is possible.
>>
>>Thanks for the time taken to reply.
|