I would tend to agree with Wayne on some aspects of this. Whilst it is
desirable that a logging program covers all aspects of a contest that all
contesters want, in practice it is not always possible.
During the transition period from paper to computer logging, a reputable
contest sponsor would have ensured that rules were not changed because a
software writer couldn't handle a particular rule. This may or may not be
the situation now. In this case, however, there is no particular rule for
the software writer to comply with, therefore Wayne is quite correct in not
addressing the request as a priority.
The original rule (formulated whilst I was a member of the sponsoring
committee) stated that only one transmission should be made at any one time.
This was virtually impossible for mult-op entrants to comply with, as the
2nd station could only call new mults and had to time their transmission
with those stations rather than their own run station. This is nothing to do
with logging, but the rule was changed (whilst I was committee chairman and
IOTA Contest adjudicator) to relax the situation. The run station could then
concentrate on just that and the mult station could chase mults.
Now comes the crunch in that how does that work in practice? Well, in my
opinion as a former committee member and organiser/op of a succesful
multi-op venture, the answer lies in the operating technique. It is up to
the team to work with available logging software and develop a slick and
efficient operating technique that will cope both with the vagaries of the
rules and the software. Isn't that what contesting is all about? Or have we
lost the plot somewhere??
The IOTA contest throws up some interesting differences to the major events,
and this is where it begans to become interesting. Any old logging program
will tell you that G is zone 14, also in ARRL an operator can reasonably
expect 1K, 100, 400 (in the UK, really?) will be standard reports. Whilst
most IOTA Refs are country specific eg EA8, P4, GU, many aren't eg those off
mainlands and I would expect a logging program to understand this in its
multiplier checking process. I saw a posting regarding Cluster Spots, here
is a typical example. The entrant should be considering how to deal
efficiently with this and not expect the software writer to come up with a
solution for him.
Serial numbers always add interest and intrigue to a contest. Had we
listened to the moans and groan a few years ago, these would have been out
aligning the contest to the CQ/ARRL template, and of course making easier
for the DVK guys to record a Wav file and hit the button "59 Europe 114."
Thanks goodness we didn't lose the plot!
I have now operated MO as GU6D, GU7D and GU8D from 1996 to present, and
initially when no logging program supported the multi-operator section. We
have and are developing new operating skills and techniques. We are able to
run at an average of 120 Q/H over the 24 hours even with a complicated
exchange eg 59(9) 2783 Europe 114 and integrate our mult station to take
passes, grab spots, S&P and move people around bands/mode. OK the serial
number bit is a minor irritation but I can assure you if that was the only
thing keeping us from top spot (having placed 9th initially up to 2nd, then
I think I would have more sympathy with the request!
There are a few issues that I would like to see addressed that are available
in NA and other programs, but I will contact Wayne for a bit of negotiation
once I have paid my subscrition and become a bona-fide user!
Chris G3SJJ
-----Original Message-----
From: writelog-bounces@contesting.com
[mailto:writelog-bounces@contesting.com]On Behalf Of W. Wright, W5XD
Sent: Monday, February 03, 2003 10:00 PM
To: writelog@contesting.com
Subject: Re: [WriteLog] RE: Serial Numbers and IOTA (as example)
> 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.
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
|