[MacLoggerContest] Contest Operator Support Features

[Jack Brindle]

On Feb 6, 2005, at 3:26 PM, Jonathan G0DVJ wrote:

> (b)  Multiplier/Bonus checking -  This is about signalling that the 
> current QSO being logged is potentially a new mult or bonus 
> opportunity either on the current band/mode or potentially also on 
> another band/mode (in the case of multi-band/multi-mode events).  
> Obviously the realtime summary scores should be updated after the QSO 
> is committed to the log if the mult/bonus totals per band/mode & 
> overall are affected - i.e. the potential was confirmed.
> Something I have yet to see on other software but wonder if we could 
> be the first, if others think its useful, related to this potential 
> value of the stations you hear (when running a frequency) is to make 
> an easy way to quickly log more than one partial call at a time - 
> since you often get called by more than one station.  If the potential 
> value of each was flagged you could select on the basis of value if 
> you desire.  At a minimum it could provide a scratch pad of partial 
> calls heard since my increasingly bad short term memory means I often 
> forget what I have heard as a call after completing a QSO with another 
> station.

Interesting, but useful? This might come from an HF-only perspective, 
but I have been convinced by the local big guns that it is better to 
concentrate on getting as many QSOs as possible and not mults. Along 
the way mults will come. Yes, there are a few times that all caution 
should be thrown to the wind and you may go after that last mult. But 
in general it is a bad idea that ends up wasting time. Having said 
that, this is a case where packet spots come in very handy. With 
_valid_ information from that facility, it would be rather easy to note 
that a certain spot is a new multiplier. this _is_ commonly presented. 
Showing it from other data generally not reliable. An idea might be to 
allow the user to keep entries of stations heard, but not worked, just 
in case you come across them again. The computer could alert you when a 
spot shows up, for example.

> -  Radio should (if connected) provide frequency/band info to the log 
> as a minimum.

I believe this is a must! I should not have to remember information 
that is very easily obtained from the radio. Also, this can provide a 
cross-check to make sure you are within the proper parameters (band 
edges, mode, etc).

> -  Rotor control could act on the bearing info of the station being 
> worked (as mentioned in 1(e) above).   Low priority IMHO.

One of the principal reasons that I recently changed calls (WA4FIB -> 
W6FB) is that in every contest I had at least one QSo where the other 
guy would have a great signal, only to fade into oblivion as he turned 
his antenna away from California and towards Florida. It can be useful, 
but also very harmful.

Now I do believe that control of the rotor should be allowed through 
the contest program, just like control of everything having to do with 
the station should (antenna selection is a great one!). It should be 
user-selectable as to whether it is automatic or not.

> -  TNC could flag potential mults/bonuses to the operator as they 
> appear as spots on a DX-cluster - similarly for internet connected 
> clusters.  Radio (frequency/mode) and/or rotor could act on spotted 
> data if selected while remembering previous working frequency etc,  
> Otherwise just the option of a passive cluster viewing window on might 
> be enough for most people.  Some sections of some contest rules (e.g. 
> single operator unassisted) may prohibit cluster use so would we want 
> any flag from the configuration process to govern if a cluster window 
> can be displayed?

Packet spotting is another mandatory feature in contest software these 
days. It must allow connections through the internet, and should also 
allow the use of a TNC. It is interesting that use of internet 
connected spotting has far overtaken the use of packet-radio based 
spotting. The two use the same data formats, but the internet has 
proven more reliable.

Other equipment should be controlled as well. The next generation of 
amplifiers is/will provide a data interface for control. While 
accessories such as DVR are being moved into the contest program, there 
are other things that are beginning to be made available externally.


> - ADIF export / integration with other main station logs (e.g. MLDX 
> and others), possibly with some intelligent population of other fields 
> for the main log (such as contest name in the notes field), 
> site/location information, etc.

Support of ADIF is a pain for the programmer, but probably needed in 
the program. Should it support new ADIF definitions or even the 
XML-ADIF currently in the works? I would really like to hear Don's 
opinion on this.

There is something very notably missing in Jonathan's writings - SO2R. 
In HF contesting these days, SO2R is rapidly becoming a must if you 
want to compete. Support for SO2R has ramifications in many areas, 
including rig control and information display, band maps, equipment 
(non-rig) control and user interface. Some of the PC-based programs 
have two exchange entry areas, one for each radio! Exactly how this all 
works and plays together is still an art and not a science, since the 
arena of SO2R is still developing. it would be interesting to hear from 
hams with SO2R experience for their ideas on how a station should work, 
and how it should be presented to the operator through the computer.

I guess I might add that my view of contest /station software is that 
each piece of equipment is modeled in the program, and presented to the 
user in some fashion. An antenna rotor might be presented as an 
azimuthal map of the world with a pointer showing the direction. The 
radio could be a bandmap with a pointer indicating the current 
frequency. Spots would show up on the bandmap. The antenna system is an 
area ripe for modeling, with each antenna having some sort of indicator 
which shows the specific aspects of the antenna (direction, SWR, etc). 
Integrating all this and presenting a useful display to the operator 
that is not overpowering, even in the late stages of a contest when the 
op is very tired, is an interesting and challenging task for the 
developer.


-Jack Brindle, W6FB
=======================================================================