Linux Odyssey 2010 - Logging Software
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!
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide