This is part of a series on trends in studio-transmitter links, or STLs.
Tommy McElmeel is broadcast telemetry and regional engineer for Family Radio. He worked for K-LOVE from 2007 to 2020, including seven years as the IT infrastructure manager and the rest as infrastructure architect.
Radio World: Tommy we’re asking our experts to identify important current trends in how radio delivers audio and data to our transmitter sites.
Tommy McElmeel: The biggest change is a reliance on internet to provide audio for transmitter broadcast.
Although this is a less expensive model, reliability also needs to be considered. In some respects, the internet is still a bit like the wild, wild west. It is far more reliable than it was even five years ago, but I believe there is too much reliance on service providers like Azure and AWS.
As a lifetime IT engineer, I’m always a fan of multi-path. Have a primary path, perhaps your high-bandwidth and less-expensive path, but always have a backup path with automatic switching.
Be careful how you use SaaS. When you give up some control of your system in favor of saving money, it might come back and bite you when there is a failure that is out of your reach.
RW: How can a broadcaster choose the best option from among the choices available, including licensed vs. unlicensed, the different bands and many other choices out there?
McElmeel: The best option for audio delivery always depends on the location and which options are available. Satellite delivery is very reliable, but you cannot install a satellite dish at all locations. Internet delivery is a quick and easy delivery method but can come with reliability issues. STL can be a good option but requires two sites. There is not one standard option that is going to work at all sites. Embracing all options available and picking the best option (or options) for a particular site has always been my goal.
RW: What role do satellite internet-based systems like Starlink play now?
McElmeel: At Family Radio we have started deploying Starlink to some sites for telemetry and control. This is a great option, especially when there isn’t another high-bandwidth solution available. Even if there is, Starlink is likely less expensive if you’re not providing audio 24/7. If you are providing audio over Starlink, you might get bumped into the next bandwidth bracket. At that point, the cost might be more than a terrestrial solution available.
RW: What are the implications of the growth in use of the cloud in radio air chains?
McElmeel: My largest concern for having the air chain in the cloud is the reliance on service providers like Azure and AWS. In the past 10 years or so I can think of two instances where AWS services went offline for one reason or another. When that happens, a large portion of the internet just stops working. Several DNS services fail, a lot of e-commerce fails, and if your air chain relies on these services, your audio fails.
RW: What options does a station have if its site lacks cell or hardwired connectivity?
McElmeel: For the most extreme transmitter sites, traditional satellite is a great option. If you’re running IP and audio, it can get expensive. Starlink is a much less expensive option, but I need to gather more data over time to speak on its reliability. At the five or so sites where Family Radio has deployed Starlink, we have had great success so far.
RW: Many transmitter sites lack substantial IT infrastructure. What are the implications of that?
McElmeel: As radio equipment has grown and improved, the reliance on IT infrastructure has grown exponentially. If we aren’t there already, the time is coming where equipment manufacturers are going to assume internet connectivity will be present at the transmitter site. For sites that lack substantial IT infrastructure, it’s going to become more difficult to support those sites as equipment is replaced and modernized.
In my telemetry role at Family Radio, I want all the data I can get from the equipment to help troubleshoot issues efficiently and accurately. I want devices that can self-heal and report back to HQ that there was an issue. More and more this is going to rely on reliable IT infrastructure.
RW: What are the implications of using IP links for obtaining support and configuration help from suppliers?
McElmeel: When inviting suppliers and vendors onto your network for support, security is the first thing that should be considered. Yes, we want to make it easy for support personnel to get to solving problems, but not at the expense of security. Far too many times I’ve seen radio equipment with Telnet enabled when SSH is available. Default user names and passwords are almost ubiquitous at transmitter sites. Equipment needs to be secured, yet accessible to those who require legitimate access. Layered security is required.
RW: What can we learn from recent natural disasters in North Carolina and California about keeping links operating?
McElmeel: Disasters come in all shapes and sizes. Sometimes it’s a bad firmware update on a single piece of equipment and sometimes it’s a hurricane. All we can do is build the most reliable and redundant infrastructure that the budget will allow.
I believe that the difference with large disasters is that radio plays a different role. We aren’t talking about the inability to conduct e-commerce, we’re talking about people’s lives. In large-scale disasters, people are looking for information, and radio might be their only line of communication. That might be updates on the situation, or advice on how to prepare or evacuate. People also look for reassurance that they’re going to be OK.
Radio needs to function during these events. Engineers need to design robust and reliable systems to ensure that messaging can continue to get out.
RW: What practices do you recommend to create redundancy and ensure continuity of operations; and how can we secure the “pipe” against external threats?
McElmeel: Redundancy begins with trying to imagine failures that you have never seen or maybe have never occurred. How do you keep your system running when you encounter various issues. Sometimes two “never been seen before” events happen at the same time. Any single point of failure that you can identify in your system should be eliminated, when budget allows. Sometimes you’re forced to compare the cost of redundancy against the cost of system failure.
Meanwhile it’s usually not the “pipe” that the bad actors go after, it’s the unsecured equipment. Default user names and passwords should be changed. Telnet should be disabled in favor of SSH. Firewalls should be utilized at all points of entry to the network. Relevant firmware updates should be applied to aging infrastructure. Equipment that cannot be secured should be replaced with a modern device.
Read more about STL trends in a free Radio World ebook.
