With the ARRL Field Day just around the corner, I decided, in the spirit of my own Linux Odyssey that I should find and use a new logging program. It is the search for this program that prompted these thoughts.

If you are not familiar with Field Day, the objective, from the League’s site:

To work as many stations as possible on any and all amateur bands (excluding the 60, 30, 17, and 12-meter bands) and to learn to operate in abnormal situations in less than optimal conditions. Field Day is open to all amateurs in the areas covered by the ARRL/RAC Field Organizations and countries within IARU Region 2. DX stations residing in other regions may be contacted for credit, but are not eligible to submit entries.

It is a chance for Amateur Radio operators to get out and operate, to practice our skills and give the general public a chance to see what we do. And for many Amateurs, it is a chance to operate and rack up as many Qs (short for QSOs or contacts) as possible. In order to figure out who you have talked to, on what bands and in what modes and the associated multipliers, you need to record these details, rapidly, correctly, and accurately. It is 24 hours of frenetic activity followed by several days of sifting, sorting, and filling in the paperwork to record the score and submit it to the League. Field Day is not the only contest that Amateurs participate in, although it could be argued that it is the biggest, so you would think there would be several packages out there, created by frustrated individuals, for making all this minutia easy to capture. And you would be…well…wrong. Oh, there are a number of packages, but there are only a couple that are the go to packages and oddly, ones that are purely Open Source, are frankly, lacking: in features, in cleanness, in usability. So, I started asking around and came up with some requirements for a new logging program, based in Open Source and able to do what needs to be done.

As a reference, let me start with the software I have used previously to log, and that worked extremely well for Prince William County ARES when we participated a couple of years ago as a 2F station. With two operational stations, one Get On The Air station and a VHF/UHF station, we needed a logging solution that could be networked (as all Field Day teams need if there are more than one station operating) and we used N3FJP’s Field Day logging software, network version. The software is Windows-based, written well enough to run even on Windows 7 (a statement for software written in early 2000), and has a clean interface. Now I could have used N1MM’s software, which I hear is also good, or others, but we used Scott’s because that is what we had.

But this is just a starting point. As anyone who has used these packages can tell you, you need to make sure you back up the single log file to prevent corruptions from creeping in (the programs write to a shared file on one of the machines using Windows peer-to-peer networking) and wiping out all your work and the reporting mechanisms are, well, less than robust. So if I had the time and energy to write my own logging program, here is what I would like to see.

Firstly, I think it would need to have a robust database. Personally I would like something in a relational database although I am sure someone could implement it with an embedded database. I am also leaning towards a relational database for the ability to do the necessary reporting and submission. Many contests want the logs submitted in a couple of accepted, standard forms, but those forms can and do change over time, and if the ability to dump data is flexible, then it makes the program more valuable along the way. It also will allow the user to populate the database with changes that occur to modifiers and multipliers over time, again facilitating easy calculations at the end of the contest. If you have ever been responsible for compiling the submissions for Field Day, you will already be thinking and I could insert links for media hits, pictures for the website…. You are getting ahead of me. But yes, that too.

Secondly, it has to be fully networkable. Since we are talking about running it on Linux, we certainly do not need a dedicated server. The real question is do we make it a client-server application or an n-tier application? My initial preference is a full on LAMP (Linux/Apache or some other web server/MySQL or similar database/Perl, Python or other scripting or CGI engine) solution. To me, it would be more straightforward to write, but I am willing to be talked out of that for a good user interface in a client-server model.

Third, it has to be quick. As I said, Field Day is frenetic, with contacts slamming in sometimes as fast as the operator can enter the other station’s call, class, and section. I have witnessed as many as 15 Qs a minute per station. While not high from a transaction standpoint (after all I have pushed MySQL to thousands of transactions a second), the ease of inputting the data, checking it for duplicates and accuracy, especially for section information, is vital before the transaction is written to the database as a saved record. This is a delicate ballet between reads and writes and error correction.

Finally, it has to be easy to use, both during execution by the end-user as well as during the installation process. Software that is not easy to use is not going to be used, and people will get frustrated. Frustration on Field Day is not a pretty sight.

Now, here is one of the reasons I think an Open Source package would be better for Field Day (or other contest logging) than the existing packages, especially a LAMP implementation: anyone could interface with it. Suppose you have a handful of machines of various operating systems. If you have worked Field Day you know that is the case. So a flexible logging system would mean everyone could play, rather than having to match one operating system or flavor of operating system. To me, that would be a huge win.

Are there other things to put into the system? Sure. Real time statistics, such as by band, mode, and operator are always good for bragging rights during the event. The ability to add in other things that are needed for Field Day scoring, such as being able to integrate pictures and media links and the ability to then turn around and output data for the club web site are only some of the things you could add in. But I think this is a good start.

Good luck to everyone on Field Day 2010. I hope to hear you on the air. And if you decide to build this, let me know: I will be happy to test it and shamelessly promote it.

Shameless Promotion If you are just getting started with Linux as an Amateur radio operator, or are a seasoned Elmer, Linux Journal would like to hear from you. Send your questions, tips and tricks to the Hamshack at hamshack at linuxjournal dot com. And remember to visit the Hamshack here at Linux Journal and follow the shack on twitter @hamshack!