[MacLoggerContest] Exchange entry methods

[Jack Brindle]

Jonathan and I have been having some rather interesting discussions 
about these topics for the last few weeks. First. let me thank Jonathan 
for kicking this off, and for Don hosting it. I think, and hope, that 
we will get some great ideas from these discussions.

As I told Jonathan, I have been working on a carbon-based contest 
logging program for two years now. It has a LOT of code that works 
rather nicely. After all this time, it is NOT ready for use in a live 
contest. I have learned quite a bit along the way, and plan to add more 
as I move forward. It would not keep me from picking up someone else's 
program (Don?) if it is better than mine. It has given me quite an 
appreciation for the things that the PC logging authors have done in 
order to get to where they are.

At this time I mostly use N1MM Logger for my contest logging.  The 
reason? It's free and does the job. My most recent use was in the NA 
Sprint SSB on Saturday. There were things it pointed out (again) to me 
that I don't like, and things I do. in fact, all of the PC/Windows 
programs have features that are very good for contesting. But they all 
have one things I really don't like - they are not meant for my 
platform of choice... ;-)

The most important area for the user in a contest program is exchange 
entry. As Jonathan has pointed out, there are two basic ways in current 
use.

> 1) The operator is faced with a logging line consisting of separate 
> dedicated fields...
> 2) The operator is faced with one single field into which he/she can 
> enter any of part of the contest QSO exchange...

Both have plusses and minuses, and some PC programs use either or both 
methods. The first method has a big problem that at all times you have 
to know what field you are in. Typing a name into a serial number field 
gives strange results. Almost all programs use character checking for 
field entry, so that alphabetic characters are not allowed into numeric 
fields. Still, typing a name into a number field can be done, and 
results in no change to the number field, along with frustration after 
the user discovers that s/he typed the characters for nothing, and now 
has to re-type them

The second is rather interesting, and very challenging to code. Trying 
to figure out what a piece of data is for requires some magic by the 
program and its author. Some are easy - the NCJ Sprint has only one 
numeric field which must be for a serial number. It also has two 
alphabetic fields, one for name and the other for 
state/province/country. It is possible that a name might actually look 
like a state, making it difficult to determine which is which. The ARRL 
Sweepstakes has two numeric fields - serial number and check. For 
serial numbers from 1-99, it is impossible to determine whether the 
numeric data is the serial number or check. PC authors have applied 
rather interesting logic to these areas, and we can learn from their 
efforts.

There may be other ways of doing this, however. Typing data "blindly" 
(maybe into a hidden field), having it interpreted, then transferring 
it into the appropriate fields might be very useful. But there may be 
other ways that simply have not been considered. Data entry using a 
tablet and MacOS X's character recognition might produce interesting 
results - as long as the tablet is not troubled with RFI. There may be 
other methods that are just waiting for innovation.

It should be noted that an area that is mentioned in another thread 
should also be considered here. Callsign dupe checking and "Super Check 
Partial" are very useful utilities that directly apply. Dupe checking 
is a must for contest programs. It must be VERY fast. Having to wait a 
considerable time for a database to complete an entry search is not 
acceptable. Unfortunately, some of the PC-based programs have this 
problem. It is very notable when your QSO count gets above 400 or 500 
QSOs and is very aggravating.

Super Check partial is something that should be included in any contest 
program at this point. It not only checks the callsign (and offers 
possible completions), but also can enter data into various fields. 
This data has been accumulated from past contests, and may be right or 
wrong for the current contest. It is very helpful, though, when you are 
trying to pull a station through QRM, or late in the contest when you 
have simply typed too many keystrokes. Note that it does not keep the 
operator from having to copy the entire exchange since the data shown 
might not be correct.

> -  for speed, the entry should be entirely keyboard based and no 
> mouse/pointing required
This is the cry of the PC user - but is it really valid? As an example, 
most ops keep one hand on the transceiver VFO knob in order to QSY for 
S&P. It seems that an alternative would be (and in practice, is) to use 
a Powermate for this purpose. Tapping the PowerMate could cause it to 
perform  some other function, like field movement or window selection. 
Again, this is a rule that came from a time when the PC had very few 
entry solutions. That no longer applies, and has never applied to our 
platform.

> -  again for speed reasons, as well as ease of thought, single 
> keystrokes should be used (i.e. no sets of key combinations to learn 
> for control functions).
In the PC World, extensive use of multi-keystroke entry is required. We 
may be saying the same thing differently here, however. Multi-keystroke 
entry should include command/option + key entries. There are just too 
few 'F' keys to support the contester's needs. I agree that entries 
that use two separate keys to be pressed in sequence is definitely not 
the way to go.

> -  for cases where corrections must be made - it must be easy to amend 
> the right field contents quickly
Yes! But getting to them quickly is not something that has been 
properly solved anywhere yet.

> -  for reliability and integrity, particularly realising that many 
> contest efforts are from field locations perhaps using generators, 
> QSOs should ideally be sent to disk after they are individually 
> committed, so that if power is lost for example, only 
> uncompleted/uncommitted QSOs might be lost when the system is 
> restarted.

Yes, but in what format? I had an especially aggravating time with N1MM 
Logger last November when the program crashed and refused to restart. 
The program uses Microsoft Access database to keep all information, 
relying on database functions to quickly find the info. Getting at the 
data is not easy, and pretty much requires the database. I was 
eventually able to figure out some sequence of actions to get things 
going again (it still crashed periodically after that due to a flaw in 
the database info). I learned a very important lesson here - do NOT use 
a database for data storage.

We may wish to discuss the QSO file format, leaving it open (even if 
the code is not). My own program uses a 128 byte binary format with 
both fixed and definable fields, depending on the contest. It is read 
and written very quickly, but because of its binary nature, I am no 
longer sure that it really is the way to go. For example it keeps the 
date and time in Unix binary format (number of seconds from Midnight, 
Jan 1, 1970). Easy for the Mac to use, but not easy for a human to 
read. Don has experience with this - what do you think?

> -  from a computing viewpoint, the application should be 
> multi-threaded in the sense that entering a QSO exchange should not 
> hold up other features happening in background or parallel (e.g. a cw 
> or voice keyer could be running while the operator is entering data 
> from the exchange that he/she has heard).

I wouldn't even consider this at present. How the program does its 
thing should be left to the author, unless a proposal for an 
open-source project is being made. The Mac inherently gives us the 
resources we need to keep various tasks out of each other's way. For 
now, we need to define what the program needs to do, what the user 
sees, and what it does in reaction to inputs.

Enough for my turn on the soapbox. Next...

Thanks again, Jonathan.

-Jack Brindle, W6FB, ex-WA4FIB
=======================================================================