I Hate Logging Software

Keeping a log has not been legally required for most hams for decades yet we almost all do. The only common exception is VHF/UHF FM. We keep logs for awards, to remember and greet new and old friends from conversations past, for future reminiscences. Until perhaps 2000 logs were mostly kept on paper and now it's almost all by computer.

Those who are forced to use paper during PC-less operating such as on mountaintops computerize their logs after returning to civilization. Yet there remain holdouts, sticking with paper, usually for aesthetic reasons.

My first experiment with computer logging was for contests in the late 1970s. Other than a bit of playing with computer contest logging with CT in the following decade my log was paper up until my long QRT began in 1992. When I returned to the hobby in 2013 my logging was solely done by computer.

There are plentiful alternatives from which to choose, free and commercial. Back in 2013 I looked at N3FJP, Log4OM, DXLab, HRD and a few others. All have their pros and cons. There is no one right answer for everyone. Free software was desirable for a first choice since I suspected I would want to migrate to something better. I am not averse to paying for good software and I did trial a few of those products.

I settled on the (then) non-commercial version of HRD (Ham Radio Deluxe). For me it had the best mix of usability, DXCC tracking, spot display and ancillary data. Also important to me was the ability to put the daily log and contest logs (imported after each event) in separate data bases and have all data bases contribute to DXCC tracking. Entering rapid-fire QSO data is not great but tolerable.

Several months ago the performance of the old HRD began to suffer gretly under Windows 10. It seemed that every update from Microsoft creates backward-compatibility problems, which is not unusual. So far as I know the newer commercial HRD does not suffer from these problems because they update the product as necessary to stay current with Windows.

After 7 years of being reasonably happy with the old HRD it was time to move on. I revisited products I first looked at in 2013 and a few others that appeared to be popular. Here is a partial list of what is important to me in daily (non-contest) logging software. Your priorities may not be quite different.

• Continuity and support: Will there be support and updates for years to come? Too many niche products die when the developer dies or loses interest.
• Rapid QSO entry: Outside of contests my QSOs tend to be short. I need to be able to enter start/stop times, reports and perhaps name with a minimum of keystrokes and mouse gestures.
• Band map of DX spots: Spotted calls graphically arranged by frequency tells me what is where at a glance. Maps and lists are poor alternatives.
• Automatic log lookup: Did I work the station before? When, where and name are wanted.
• DXCC tracking: Is a station a new country or band-country? Is the country correctly derived from the call sign? DXCC needs per band tied in with spotted calls.
• Ancillary QSO data: IOTA, QTH, free text comments for antenna and power, etc.
• Performance: I want everything to happen instantly. Processing delays for large data bases of contacts are a problem.

I am flexible rather than rigid in regards to logging software requirements. Not only is perfection unattainable most hams find that their requirements evolve as they become accustomed to a product and their operating preferences change. You think: if it can do this why can't it do that? Your thinking evolves, software products evolve, and indeed everything in our hobby evolves.

In short, I will make no recommendation. Indeed I rarely find recommendations useful. Perusing online reviews of logging software is more likely to confuse than enlighten. Reviews are typically made by those either very happy or very unhappy, and those eager to declare "me too!" Of the products I've tried the reviews are unlikely to agree with my experience.

Rather than making a recommendation I'll talk more generally about what to watch out for when investigating logging software. That is far more likely to be useful. Making a lazy choice can lead to frustration. Consider what is most important to you and then play with a few of your top candidates before making a decision.

Customization and the user experience

Beware software that is infinitely customizable! This is typically promoted as allowing each user to create a unique experience by adjusting, well, just about everything. What it instead screams to me is: "we don't know how it should work so you figure it out."

Creating an effective user experience (UX) is difficult. I've had to do this myself in my professional career and I have closely worked with those whose job was to improve product UX. You might think that a ham who produces ham software would be ideally placed to get it right. Regrettably this is often not the case.

Mostly what we have is users adapting to the peculiarities of the application or customizing it to the point that only they can use it. Once you've reached that point it is difficult to change. Instead it is our nature to rationalize and to defend our choices vociferously.

Of the products I've tried I think the worst in this category is DXLab. It has a large base of enthusiastic users. I've now come back to it for the third time and I still find it impossible to like. Window management is weird, the UI obsolete, customizing it to point of usability is long and difficult and there are simple bugs that seem to persist.

It's not all bad, of course, just not what I am comfortable with. Many like this type of software so perhaps you will as well.

Feature creep, or "bells and whistles"

Mature products frequently run into this problem. Whether in a bid to differentiate from competitors or to meet the needs of diverse and small numbers of users feature count increases with time. Obsolete and rarely used features are not removed. As features increase there are more things that can break and interactions among those features can decrease usability and have deleterious interactions.

Ham logging software is no exception to this rule. Perhaps the product adds an interface to a vintage rig, adds tracking for the "Worked All Podunk" award or supports Windows XP machines. Continue this for several years and the software can begin to collapse under its own weight. The majority who stick to the basic features can find their use impaired by features they never asked for and don't want.

In fairness developers are often doing no more than responding to requests from their customers or keeping up with new technology. But when a feature is added to a mature product rarely is the total UX reconsidered. It is usually left to the user to decide which features to enable or disable and to decide how they ought to interact (see previous section). Adequate testing becomes difficult to nigh impossible since feature interactions grow faster, often far faster, than the feature count.

There is one logging software product that has become so bloated with these bells and whistles it is jokingly said that for every 5 bugs fixed there are 6 new bugs introduced. Those bugs can become increasingly troublesome and software updates a source of user angst.

Oftentimes less is more.

Real-time application interfaces

The more sophisticated logging software support real-time interfaces to other amateur radio applications. These include:

• CAT for transceiver control
• Rotator control
• Serial interfaces for antenna, amplifier and filter switching and related contest peripherals
• UDP broadcasts to send or receive QSO data for storage and further processing
• Software API to receive QSO data from digital engines, including FT8, PSK, RTTY and CW
• Online databases to retrieve biographical data by call sign
• Upload QSOs for electronic QSL (confimation)

This is not a complete list. Not even close.

I prefer to use the absolute minimum of these interfaces. CAT is obviously needed and I am planning automation for antenna and filter switching. I am making progress with SO2R switching, including keyer and mic control. All the rest I am avoiding.

It takes time and effort to properly implement these interfaces and to keep them working. Even when done well problems will arise due to software updates. Communication glitches result in database synchronization errors that can be difficult to discover, track down and correct.

I prefer to transfer QSOs manually at month end between logging applications and to LoTW. Many hams enjoy fiddling with these interfaces and features. I am not among their number. Simple is good and good enough is good enough.

I go further in that I prefer software that does not support unwanted interfaces since that can lead to bugs in the features I use (see above). Where there are optional modules for these interface features I don't install them, and if the features have configuration switches those switches are set to off.

Support

Products built and maintained by a sole developer tend to have a limited lifetime. When that person retires or dies the product goes into stasis and will eventually become unusable, whether through changes to unrelated software that it uses or no support for future equipment and services. I have been very lucky that the old HRD has continued to work for me for 7 years. Over the past year I have endured increasing occurrences of software glitches.

Support and product improvements take time and effort that users must compensate, and payment is deserved. There are many free alternatives if the willingness to pay is low. Of course those who pay expect good support and should get it. HRD was a free product that now has a license fee to pay for support and new feature development.

A few products are both free and well supported by a team. N1MM Logger+ is an excellent example. Despite contests being its primary application it has been successfully used by DXpeditions and by many users for daily logging.

When you choose logging software how confident can you be that it will be there tomorrow? To protect yourself make sure the application can export the QSO data base in ADIF format, and test that it can by making periodic backups. In future you can import the data base into another logging application. Insist on that to insure yourself against future obsolescence.

What I'm doing now

My current daily logging software is N1MM Logger+. It meets most of my criteria and I am most familiar with it since it my contest logging software of choice. Where it misses my criteria, especially with regard to DXCC tracking, I transfer logs to HRD monthly at the same time I upload to LoTW. It was easy to import my log from HRD using ADIF.

The QSOs are kept in a separate database from contest logs. I have a "Contest" database in HRD to which contest logs are imported after every event. FT8 logs for 6 and 160 meters are directly uploaded to LoTW from the WSJT-X log but not exported to N1MM and HRD. While most hams want digital and non-digital QSOs in the same database I prefer the separation. LoTW does all the category assignments that matter to me.

The screen capture shows which N1MM windows I use for general logging, using the DX "contest" selection. There is the band map with both self spots and cluster spots, the Telnet window for the cluster and a map with the terminator and spots. The log window includes past QSO lookup. A tally of QSOs and countries per band and mode is in the summary window

CW and phone messages are easy to program and use. All are keyed from the entry window or in F-keys. This is superior to using the Winkeyer buttons. I keep CW speed under keyboard control rather than configuring that option only for contests.

Since I have more than 10× as many contest QSOs as non-contest QSO the use of separate databases is helpful. I generally do want to see when and where I've worked a station before but not if it was in a contest. To me they are very different and unrelated activities. I like that this is natural to N1MM Logger+ as it is for HRD. Most logging software has support for just one database.

Before and after contest several windows and options must be configured. That is a downside of using the same application for contests and daily operating. There are ways to smooth the changeover which I have not bothered with. I haven't even decided whether to stick with N1MM Logger+ for daily operating.

I may yet decide to try something different. For now it works well for me and my style of operating.