The Contester In Me...

Foundations of Amateur Radio

So, I have a confession to make. I'm a contester. I'm not ashamed of this. While I'm in a confessing mood, I'll also mention that I've not participated in many contests in the past few years. This is not for the want of desire, but for the lack of motivation to fix things in my shack that are fundamentally broken.

On the weekend I participated in a local contest. I took part for six hours, got on-air and made noise, made about 30 contacts, had a ball. I wasn't playing to win, though I did use the opportunity to refresh and hone some of my rusty skills.

The next day I spent much too long converting my log into something that the contest organiser asked for. I also discovered that there was a duplicate entry in my log, not something which I'd expect with only so few contacts, but a reflection on the tool I was using to create my log.

I started writing down what I learnt from the experience, operating from my own shack, documenting what worked and what didn't.

I commented on several things relevant to me, but to give you a flavour, my operator position is terrible because I'm logging on my main computer and the radio is side-on when I'm facing the computer. The sun was shining directly into my eyes when facing the computer. Holding a microphone I didn't have hands-free, I still don't have an auto-keyer to save my voice, my foot pedal didn't work and my data interface was on loan to another amateur.

As I said, these things are specific to me.

Logging was worse.

It didn't quite bring me to tears, but as the contest went on, it became a problem. I started to write down what was wrong with the tool I was using with a view to submitting patches to fix it when I realised that it wasn't actually built as a contesting logging tool, so I stopped and instead started writing a new list, one that describes what a good contesting tool looks like. It builds on a decade of using different tools and participating in contests in all manner of different situations, from special portable event activations, through to the annual top-tier contests run from a purpose built contest station and everything in between.

So, what does the ideal contesting tool look like, for me?

It needs to be cross platform, as-in, I should be able to use it on whatever computer I have access to, my Linux workstation, a Macintosh Laptop, an Android phone or tablet and while I'm at it, Windows and iOS and I think it should be able to run on a Raspberry Pi. In other words, there shouldn't be a situation where you cannot run the tool because you have some random combination of operating system or CPU that the developer doesn't support.

It must be open source. By that I mean, the code should be available to the entire community. There are too many stories of great tools dying or being held hostage by individuals or small groups. The tool should continue to exist and be usable regardless of the participation of the original developer. Users should be able to fix things, add functionality, change themes, whatever.

You should be able to customise it because not every contest needs the same information. For example, the John Moyle Memorial Field Day, a contest run every year during March in Australia requires that VHF and UHF contacts record the maidenhead locator, a four or six character message that designates the location of the station. This is used to calculate distance between two stations and award points accordingly. Such a requirement isn't needed in most other contests.

Some contests are considered friendly contests, like the Remembrance Day contest in August. It's common to exchange your name, details about your station and have a chat. You'd be unpopular if you used that approach for the Oceania DX, the CQ World Wide or the CQ WPX contests. In other words, some fields are expected for some contests, but not for others.

The tool needs to be able to show if a contact is valid by whatever means the rules for a particular contest decide. It needs to automatically log the time, keep track of previous entries and know about the super check partial list to validate partial callsigns.

The user needs to be able to use either a keyboard or mouse, or both, to do all the common contesting data entry. No dependency on crazy keyboard shortcuts, no requirement to click the mouse to make an entry, in other words, the tool needs to be able to get out of the way of the contester.

I think it needs to have a plug-in system to accommodate different rules and it needs to be able to export data in whatever format the contest organiser expects.

You should be able to use it without needing to be connected to the internet during the contest, it should be easy to update and have the ability to keep a station log for all the contacts ever made.

It would be great if it could also import existing logs so you can start to consolidate older logs.

Having spent quite some time looking for such a tool and failing, I've come to the conclusion that there's only one thing for it, I'm going to have to write my own tool and it would be great if you could help by sharing your opinion on the matter.

At this point I'm looking for suggestions on what you think is needed for a great contesting tool. I realise that for some, pen and paper is sufficient, and I'm not trying to dissuade you from using that, I've used it myself on more than one occasion, rather, I'm asking if you can think of things that it should do out of the box, things that are basic functionality that you would like to see as part of the design.

You can find the project on my vk6flab GitHub page, comment on Reddit, or you can drop me an email, [email protected].

Look forward to hearing from you.

I'm Onno VK6FLAB