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.

Reflections on IARU HF World Championship

I didn't operate in the IARU contest last weekend. However, my station was active with a guest in the operating chair: Vlad VE3TM. I didn't take a picture of him during the contest so I'll direct you to his QRZ page.

Since I'm not a fan of summer contests, it was an opportunity for Vlad to play with a bigger station than his small one in Ottawa. His station is also plagued with noise, a common occurrence in urban and suburban settings. 

I benefitted since this was the first time someone else operated my station in a contest. It was useful to learn how the station automation, operating desk layout and equipment performed for another contester. My job during the contest was to answer questions and fix any problems that might arise. Luckily, none did. I kept the coffee flowing and otherwise kept out of his way.

I designed my station automation to be intuitive but that is no guarantee that it will make sense to others who sit down to use it the first time. I directed Vlad to my description of it on the blog and that proved to be sufficient. I explained how the SO2R system worked and how to use the many rotators. There's a lot to learn and it can be overwhelming. I'm not the best judge of the learning required because I'm familiar with the station.

Aside from 2BSIQ, which Vlad has never done, the best way to exploit a large station is to always be running on one band and hunting for stations and multipliers on other bands. That takes practice. Propagation was such that only 15 meters delivered consistently strong runs, mainly to Europe. For the most part he kept the stack pointed northeast. Runs were limited on 20 and 40 meters to times when conditions were favourable. Part of that is due to stations migrating to the higher bands to take advantage of the high MUF.

Marginal conditions on the other bands -- 10, 80 and 160 -- proved difficult since he was in the low power category (100 watts). Vlad usually operates low power in contests and that's what he did in this one. Since my amps are manual tune (A1500 and L7) he avoided another point of complexity while operating an unfamiliar station.

At the end of the contest he had a respectable claimed score of over 700K points and more than 1200 contacts. Had he operated the full 24 hours and better able to exploit SO2R he could very well have had the top score in VE/W. Nevertheless, he enjoyed himself and I learned a few things about the station. That's a win for both of us.

Now I'd like to say a few words about the WRTC competition in Italy. It of course is run in concert with the IARU contest. Many participants make a point of working the competitors with their special call signs. There was a live scoreboard so that everyone could follow the competition, but with the operator identities hidden until after the contest.

The format and location of team statistics on the official web site keep changing so I don't know what you'll see when you click on the link. Before the final tally the claimed scores were shown. Those disappeared when the final scores became available a day or two later. First they were in a PDF file and then an HTML table, so who knows. You may have to take my word on a few points since you may find it difficult to check.

The final standings may be a surprise. Operators that consistently place high in major contests have mediocre results in WRTC, and vice versa. There are known and speculative reasons for this. The ones that occur to me include:

• Big scores in major contests most often are done with big stations, from stations that everyone needs for a multiplier, or from favourable geographic locations. Run fast and you'll do well.
  
• Skills to exploit the above benefits are not necessarily the skills needed to do well in WRTC. However, it does require many well-honed skills to do well with a big station, and a mediocre operator won't do well when dropped into the chair at the world's best station. The former include: SO2R; 2BSIQ; knowing where to point antennas, and when; picking complete calls from a pile up, correctly and on the first try; a recognizable call that is easy to copy; etc.
• WRTC rules reduce the value of many big gun skills. Many contesters love to find and call WRTC competitors, but aside from that they are little pistols in this contest. I'll just include one link (out of many) from my blog that enumerates skills you need to do well with a small station. Those accustomed to being a big gun may have rusty little pistol skills that they need in WRTC. You cannot simply point the antennas, cue the CQ machine and keep at it for 24 hours to place well.
  
• It has been said that contesting from Europe requires a local focus. There are more stations to work than, say, from within North America, and you must exploit that by working as many other Europeans as possible, despite the lower point value compared to DX contacts. I failed to understand that for a long time because I've never operated from Europe.
  

There is one point well worth noting from comparing the raw and final scores of the competitors: accuracy matters. The ranking of the top teams did not change but the margins did. After log checking the spread between first and second place dropped from 6% to 1%. They were very close to changing positions.

There are other notable points in the published statistics that I will not bother with. Have a close look and you will learn a few things, both good and bad. I'm sure it will be more interesting when the logs become public. I'll leave that job to others since I'm not that curious!

I have no WRTC ambitions. I enjoy watching many of the world's best contest operators do their utmost in these tests of skill and knowledge, and that's enough. Contest is recreation for me and an incentive to build a big station. That's all. 

My other great passion outside of amateur radio is cycling, and my attitude toward it is the same: it's recreation, and an incentive to hone what talents I may have. But I leave the racing to others. I didn't watch the WRTC but I do watch the Tour de France online. It was particularly enjoyable to cheer on home boy Michael Woods as he won a stage of the great race in grand style atop Puy du Dome that same weekend.

I don't know any Tour de France competitors but I do know several of the WRTC operators. It'll be interesting to hear the stories they have to tell when we next meet.

Re-boxing the Balun Designs 1113s

I repaired and reinstalled the common mode choke (balun) on the TH6. As readers may recall, the PVC enclosure for the Balun Designs 1113s shattered in several places. It was a valuable lesson on the limits of PVC and, of course, became blog fodder. In this article I'll describe how I went about the repair. The same balun on the TH7 was in good condition when I sold the pair this summer.

My first decision was how to mount the balun. The PVC enclosure is not mandatory and, indeed, many hams leave their ferrite toroid baluns unboxed so that they are well ventilated. No balun is perfectly efficient and there is heat dissipation, though small for well designed devices. Without an enclosure the balun is exposed to the elements, and that entails other risks.

My first thought was to mount the balun directly to resin backing plate. Mounted below the yagi boom it is shielded from most precipitation and is fully ventilated. 

I reconsidered when I inspected the balun and found that it does not match the device depicted on the manufacturer's web site. A picture of the currently marketed balun is on the right.

The ferrite is wound with small diameter coax. This is teflon dielectric coax that can handle far higher power than you might guess from its size. It's expensive but you need very little of it to wind baluns. Unlike RG213 and similarly sized coax, many turns can fit on a 2.4" toroid and the turns can be tightly wound (small minimum bend radius). This keeps the size of the balun small and able to fit in a standard 4" × 4" × 2" PVC electrical box. The downside is that the loss is high compared to larger coax, but that is not typically a problem at HF if the choking resistance is high (thousands of Ω).

You can see that the 1113s I have is not wound with coax. At some point the manufacturer switched from a wire-wound transmission line balun to coax without changing the product number. In my opinion the change in design is more than enough to require a product number change. Both designs can be perfectly fine but they are not the same. For example, their behaviour when subjected to high SWR or a highly unbalanced antenna (e.g. end fed wire). But let's move on.

As can be seen, instead of leaving the balun unboxed I opted for a replacement PVC electrical box. I had a spare on the shelf so it was a convenient choice that also eliminated my concerns about the weather implications of leaving it exposed. The non-coax design weighed on my decision because water, snow and ice on the bare wires is a concern.

To my surprise, the new box and the old were identical, right down to the manufacturer (Carlon) details embossed on the insides. I measured the positions of the several holes and drilled them in the same places on the new box. Not even a wire had to be bent for a perfect fit. The black cable ties with screw flanges provide support for the ferrite toroid to keep it suspended within the box.

The new box did not easily mount on the resin backing plate. The 4 mounting screws had to be forced through because they were ⅛" farther apart than the enclosure's screw tabs can accommodate. To compare the boxes I positioned the broken off tabs and old enclosure on the plate to check alignment. They were also not aligned to the backing plate holes. 

That made me wonder whether the lateral tension of the forced mounting screws played a role in the breakage. There's no good way to test that possibility. I reamed the holes on the backing plate so that the mounting screws dropped in without resistance.

Before taking it up the tower I did a quick bench test. I swept the SWR from 1 to 29 MHz with two 30 Ω resistors in series across the balun binding posts. The impedance is almost exactly 60 + j0 Ω at the lowest frequency (SWR 1.2) and it degrades, as expected, with increasing frequency. The inductance of the balun output pig tails and resistor leads is to blame.

The test was successful and also demonstrates an important lesson. Where does the balun end and the antenna begin? It's worth a few moments of thought.

The answer should be obvious: the antenna begins where the wires diverge on exiting the toroid (top centre). That must be the case since there is reduced field cancellation when the wires are not parallel, and approaches zero cancellation when they diverge as in a dipole. That is, the wires no longer form a transmission line.

The leads to the studs and from the studs to the physical antenna element are part of the radiating structure. Antenna manufacturers like Hy-Gain (I'm using this balun on a TH6) specify an exact length for the leads from the driven element clamps to the balun terminals for this very reason -- in this case the length is 6". Depending on the internal wiring of the balun the length of the driven element may need to be adjusted. Usually the effect is minor when the leads are short. For this balun that is 2" per side since the box width is 4". That's a small enough effect that I can ignore.

To reduce the risk of PVC breakage, this time I mounted the balun above the boom. It's more exposed but if the mounting tabs break there is less risk of catastrophic failure. I anticipate no weather-related trouble since the seal on the box is quite good. Sealing the coax connector is easier when it is on top so that should also do well despite being more exposed to the weather.

An accurate SWR measurement is difficult because my body was close to the driven element. On 10 meters the SWR was high with my body less than 1 meter from the driven element. The distance was limited by the short coax jumper to the analyzer and how far away I could stand without adjusting my harness. I figured it was good enough under the circumstances, and indeed the SWR measured in the shack was as it should be. Mission accomplished.

It'll be interesting to see how well the new PVC enclosure withstands the weather. It's an exact replacement for the original and we saw how that did after years of exposure in my station and, before that, in the station of its original owner.

I'll make one last observation before I close. Notice how the frequency range of the balun is specified by the manufacturer. The power rating is for 160 through 10 meters while its effective range is less. This is not surprising but can mislead if not read carefully. Also, the usable frequency in the text is 40 to 10 meters, not 40 to 6 meters as shown in the table. Is it carelessness or something more?

I have another of these baluns on the 80 meters inverted vee. I did not read the fine print before installing it or I would have reconsidered. However, although it may not be very effective on 80 that does not mean it is ineffective. For a non-directive antenna far from the house, even a common mode impedance of less than 1000 Ω can be sufficient. I haven't experienced any interaction problems when operating SO2R.

Common mode baluns have a frequency range determined by the ferrite mix, the transmission line and how it's wound. Unfortunately, measuring common mode rejection (impedance) is very difficult and experts often fail to agree on how to measure it and how to interpret the measurements. Be very careful whether you build or buy a common mode choke. The ferrite mix used by Balun Designs is supposedly custom which makes it difficult to judge without an independent measurement.

If you'd like to build your own common mode choke there are many resources. Perhaps one of the best places to learn is provided by K9YC.