[DogParkList] Re: MacLoggerDX Contest Log Fields
John E Bastin, K8AJS
jbastin@sssnet.com
Sun, 1 Jun 2003 08:34:09 -0400
I'm a contest participant, not a hard-core contester, but I'm really
happy to see MacLoggerDX moving in the direction of contesting
support.
At 11:17 +0100 06_01_2003, Jonathan G0DVJ wrote:
>
>Contesters can be categorised into 3 main types ...
...
>2 - people who make a serious or semi-serious attempt to improve
>their scores over last time and send in an individual entry to some
>degree of competitiveness
This describes my operation in contests most of the time. There are a
few contests, IARU HF World Championship, ARRL DX Contest, ARRL 10
Meter contest where I go all out with a serious effort, but in many
other contests I get in for a few hours, make a few hundred contacts
and get out.
>
>Clear easy to use interface:
>Much of the MacLogger interface needed for general logging etc. is
>superfluous for the contest logger in realtime who really needs fast
>easy visability of minimal key information.
No argument here. MacLoggerDX as a general logging program is very
good and includes a lot of information that is necessary for keeping
overall records. In a contest though, speed is imperative and extra
info only wastes time.
> I wonder therefore if either a derivative such as MacLoggerContest
>is a better idea which would interface seamlessly with the existing
>software to provide the phase 2 capabilities I outlined earlier
>above.
This is up to the developer. Trying to develop a complete second
program, even if it only amounts to a subset of the capabilities of
the main program, may create more bugs to chase and support
requirements than any one man should be required to handle...:-)
> If not, then certainly I think a contest operation Tab is essential
>to abstract away the information that is not needed for contesting
>and customise the input screen and fields required for contest
>operation.
Maybe not a Tab, since as Don as mentioned there isn't a lot of tab
room left in the UI. Perhaps a button that closes all the tab windows
of the general logging program and leaves the user with one window
where the log information of the particular contest can be recorded.
A tab for setup of the specific contest and the logging window -
clean and simple.
>
>Contest information entry:
>This has to be as slick as possible given that a good contester will
>want to accurately complete maybe 5 or 6 QSOs in a minute!!
As I said, I'm not a hard-core contester, but even I have seen my
per-hour contest clock approach 200 for short periods in some
contests. Needless to say, I don't have time to wait for anything!
> There are 2 approaches traditionally... 1) you tab (key) or
>something between the required fields for the information required
>entering each as you go.
Absolutely necessary. The order has to be correct and movement is
from field to field. Carrying this a little bit further, the contest
program I use now (running in Windows under Virtual PC) "knows" what
the length will be in certain fields in certain contests and doesn't
even require a tab - when the field length is correct, it
automatically moves to the next field.
Also, _received_ fields like signal report are in the entry screen
but skipped in the tab order and filled in with 599 or 59 since
traditionally in a contest this is the correct entry 99.99% of the
time. On the off chance that someone sends you something different, a
shift-tab will take you _back_ to the skipped field to change the
entry.
> 2) you have a single entry field and the software works out from
>what is entered which information is being entered and then puts it
>in the correct log fields.
This is requiring far too much of the contest software and begging for errors.
> This is the best since often stations you work who are
>inexperienced at contests will give the information in a different
>order from the "usual" and hence a lot of tabbing around is required
>in approach 1.
This has not been my experience in the contests I operate. In a
contest where you encounter much of this type of problem, I suspect
the rates are not such that moving around between the fields would be
as much of a problem.
>
>Configurability against rules:
>This is where the current crop of contest logging programs vary
>considerably - how to set up before the contest how the software
>will help the operator work within the rules/objectives of the
>contest but in a very easy way. If you are supporting both HF
>contests and also VHF & above contests this is a bigger challenge
>because the sorts of fields required and the dynamics and
>capabilities needed are even more variable.
This is a challenge. The contest program I use has many, many
separate modules for different contests written by the developer, and
many, many more modules have been contributed for different contests
by the users of the program.
This is extremely important for a contest logging program. Even
contests that take entries using the Cabrillo format may differ in
what information they require. The logging software has to be able to
calculate the correct final score, flag dupes and not count them, get
the multipliers correct, etc. and generate the Cabrillo file (or an
ASCII log file with dupe sheets, if required). If much of this work
has to be done by hand after the contest, the value of the program
for contesting is greatly reduced.
> Again I can offer some more detailed suggestions on this later if
>required. The key configurability required is:
> - what information is exchanged in a particular contest
> - how are points scored (on the basis of this exchange
>perhaps) in a particular contest
And every contest is different.
>
>General requirements for contest software:
> - Fast simple logging and editing
Absolutely essential.
> - Display of correct score in realtime after each QSO or edit
>within a particular contest
This is not as large a requirement for me. I might want to look at my
score during a rest break or something, but I don't need constant
score update in real time. Unless it's relatively easy to do, I
wouldn't require the effort.
> - Instant duplicate QSO checking and flagging within a
>particular contest (not based on just callsign but also band/mode
>worked too)
Absolute requirement.
> - Ability to combine realtime logging in a contest (where
>time/freq/mode etc is entered automatically) and post-contest entry
>(where time is entered manually) for when you have to
>retrospectively score a log or add QSOs logged temporarily on paper
>because of problems etc.
Absolute requirement. This may be implied, but the ability to go back
to a previous QSO and make changes even while you're logging the
current contact is important.
> - Feedback of info to operator:
> - current score overall
> - current multipliers/bonuses etc. customised per
>contest from the rules as configured above.
> - simple statistics for the contest including QSO
>rates & best DX or scoring QSO at any given time.
These (except for the score) are important features to me.
> - Keying (CW) and Voice keying (audio) are really ideal too
>in modern contesting (more detail separately again if needed).
>
This would be wonderful, but I know that this opens up an entirely
new can of worms in terms of computer-radio interface. Having the
computer handle the exchange on the radio AND the logging operation
is the ne plus ultra of contest software.
This has been a particularly sticky point with the software I'm using
now, relative to USB-serial conversion, Windows emulation, all rolled
together. Most of the time I use my memory keyer for the contest
exchanges and let the software concentrate on logging.
I'm very interested in this direction of the MacLoggerDX development,
and I'll be following this thread with great interest. If I can help
in any way on the testing end, I'll be available.
73,
--
_
/~\ The ASCII | J o h n B a s t i n K 8 A J S
\ / Ribbon Campaign | jbastin@sssnet.com K8AJS@arrl.net
X Against HTML | http://www.qsl.net/k8ajs
/ \ Email! |