Musing on a RadioInfo Standard

Standards are peculiar beasts. They typically come about from the collaboration of competitors, whether at their own behest, pressure from regulators or, importantly, pressure from their customers. Standards can permit interconnection of equipment from different manufacturers and connection of third party equipment to any manufacturer's products.

I spent several years of my life, over 30 years ago, working on North American telecommunications standards. It was interesting at first, especially working with competitors and customers in a common forum. The objectives were good, and the work attracted idealists. 

My attitude soon soured. Typical of many companies, my employer saw the work as necessary but a distraction and a nuisance from the more important objective of building and selling products. Unless you loved the work, it did little for one's career prospects. I moved on.

Standards development can be fast or slow. It goes slowly when the products affected are not in production or when customers are uninterested. With strong commercial pressure standards can be developed very rapidly. For example, when the products can't be sold unless they interoperate. Too much of my work was of the former type, hence my dissatisfaction.

We don't often think about standards for amateur radio equipment. Nevertheless, the presence or absence of standards has an important impact on us and our shacks. I use the term "standard" loosely since in many cases there is informal agreement rather than a formal standard. Formal standards require a recognized accreditation authority which does not exist for amateur radio products.

• Connectors and signals: mics, PC audio and control; rotators; band data; and much more
  
• CAT (computer aided transceiver) protocols
• Remote operation
• Computer logging and control software API
  
• Digital modes: FTx; digital audio; PSK etc.
• Peripheral equipment: SO2R; spectrum displays; and more

That is far from an exhaustive list. It is the rare ham who hasn't fussed over connectors and software configurations after purchasing new equipment. We habitually accept these annoyances with hardly a thought. But think how much easier life would be you could plug in all the existing cables and software applications to use a new transceiver.

We don't always get what we want. The lack of standards dooms us to constantly deal with each vendor's proprietary hardware and software interfaces. Manufacturers have little incentive to collaborate, and indeed see value in putting up barriers to interconnection. On the other hand, it give them freedom to develop new products features with a minimum of external dependencies.

Some of these challenges are diminishing as we increasingly interconnect our equipment with standard PC interfaces, including wireless connections. But that only addresses a subset of diverse physical connectors. Software interfaces are another matter, and is what brings me to the point of this article after a long introduction. Setting the context is worth a few minutes of extra reading (and writing).

Longtime readers may recall that I use the RadioInfo UDP broadcasts from N1MM Logger+ in my station automation software. With it I can select antennas, antenna modes and directions, avoid contention between operators, switch BPF, and more. The API frees me from dealing with the diversity of non-standard CAT and band data interfaces of transceivers. N1MM abstracts the functionality so that the RadioInfo UDP messages are almost all I need.

The downside is that I've made myself dependent on N1MM software. My station automation software is now the only practical way to select antenna. It helps that I use N1MM for contests and for daily operating. It is possible to operate the UI in manual mode for when N1MM isn't available, such as when I use WSJT-X or a different logging application.

What if I no longer wish to use N1MM? I am happy with it now but I know that can change -- nothing is forever. The team may disband, become hostile to user input or fail to accommodate future changes to the equipment we rely on. It is also possible that a better or more preferred contest logger arrives on the scene. 

My thoughts on this were driven by a couple of recent events. One was learning that among WRTC competitors, DXLog has rapidly grown in popularity. I know contesters that have switched to DXLog and I'm sure there will be others. It is not my intent in this article to compare them, and indeed I can't because I have never used DXLog. From what contesters are saying and a quick review of its features I can see why it's acceptance is rising.

The other event is that hams I know are trying to working through how to change or replace their station automation to be compatible with DXLog. This led me to wonder whether DXLog has a similar feature to N1MM's RadioInfo broadcasts. It does. While I have no immediate interest or need to migrate to DXLog it is worthwhile to consider how I might use this feature. That is, can it be done and with how much effort? Can I make my software compatible with both N1MM and DXLog?

I began by comparing the RadioInfo message content of both DXLog and N1MM. My comparison is rudimentary since the documentation for DXLog left me puzzled in some instances, and of course I haven't used it. Both broadcast RadioInfo messages using UDP and XML encoding.

If the text in the diagram is difficult to read, click on the image or widen your browser window.

Dots are for data with no correspondence between DXLog and N1MM. Black dots are for data I do not need or use in my automation software; green dots are for N1MM data that I do use. Arrows are for data with correspondence between the applications, although there may be differences that my brief analysis did not uncover. Green arrows are for N1MM data that I use in my software; red arrows are for N1MM data that I don't use.

Some data that N1MM provides, and that I don't use in my software, are needed for SO2R. Equivalent data is provided over a separate interface using the OTRSP protocol. It is used to communicate with the SO2R-Mini in my station, and which I can control with N1MM keyboard commands.

Most of what I need would appear to be available from DXLog's RadioInfo messages. However it is not that simple. A protocol is more than messages and data: there are semantics (meaning) and the process logic that dictates when RadioInfo messages are broadcast. I can adjust how my software behaves but I have little leverage over the behaviour of the logging app.

Questions that occurred to me while reading about DXLog's RadioInfo messages include:

• When a RadioInfo message is sent and why.
• DXLog's focus behaviour in Windows is quite different because there is one window visible to Windows rather than the multiple windows used by N1MM. Returning Windows focus to DXLog is likely easier than I've found for N1MM.
  
• The internal automation hooks for antenna selection, rotator control and other items are likely dissimilar. That doesn't concern me since my software doesn't use those features of N1MM. Station automation software produced by others may be affected.
• I have to wonder whether the difference in data labels in several cases reflects different functionality. For example, <app> vs. <logger>, or <StationName> vs. <Station>.
  

Many of my questions likely have answers in the DXLog documentation, sparse as it is. I have yet to bother since I have no immediate interest in switching to DXLog. There are features of DXLog that appeal to contesters and may one day appeal to me. These seem to include:

• Navigation within a single window can be easier than with multiple windows. For example, to edit the log. This can be quite a problem with N1MM when focus changes erratically when, for example, you try to edit the log while continuing to operate. It's worse with SO2R and two keyboards.
• Extensive scripting support for customization and extension of functionality. Many contesters have their own peripherals and tools that can be difficult to integrate with N1MM using its existing APIs. Large multi-op stations in particular have been receptive to what DXLog offers.
  

I like to keep an open mind on the matter, so I need to consider what it would take to have my software work with DXLog. It may seem straight forward but it never is, as I hinted above. What might push me over the edge is if two keyboard SO2R works better in DXLog. There are anomalies with N1MM's implementation that the developers have shown little interest in addressing. It's critical to my style of operating contests.

What would be ideal is a standard for RadioInfo messages. That would permit station automation software, including my own, to more easily support N1MM, DXLog and perhaps other applications that choose to implement the standard. Agreeing on a standard, and a process to get there, could prove difficult, and perhaps impossible. 

Both applications are free so any customer pressure for a standard will be social rather than financial. But once in place it could encourage other application developers to participate. Of course there are other contest loggers, but they seem to have low or dwindling use. That is true for paid and free applications.

A RadioInfo standardization process led by N1MM and DXLog is not impossible. I am in no position to say whether the parties would be willing. The amateur radio universe has certainly done it with OTRSP, ADIF, Cabrillo, APRS and others. I doubt that there are significant technical barriers even though logging applications are in some respects more complex than other software applications developed for our hobby. 

There would have to be compromises on some points and agreed disagreements on others. Unresolved differences can be managed with permitting proprietary data items in RadioInfo message as is done for ADIF and other protocols. We did the same for the telecommunications standards I once worked on. While regrettable it is occasionally necessary for progress to be made.

Without an early effort to unify the content and behaviour of RadioInfo messages it will become more difficult. As third parties, such as me and my custom software, become dependent on N1MM or DXLog's unique RadioInfo implementations, the contest loggers will get push back if they make changes to make them work the same. 

Perhaps there is more flexibility on the DXLog team since N1MM's implementation of RadioInfo is more established and therefore has more dependent third party users. This, too, is not uncommon in the commercial world I am familiar with. There is an incentive for latecomers to exactly emulate the first movers. But it would be unwise to rely on the hope that it happens in this case.

As much as I'd like a RadioInfo standard, it is not the most likely outcome. The only solution then is to be application sensitive in third party code, and all the work that entails. I am already thinking ahead to do that in my station automation software. I am hopeful that it will not be difficult.