I fondly remember the days when I was a broadcast engineer. These days, most of my work is administrative, meaning that I “fly a desk” most of the time with very little time spent doing anything technical.
Adapting to the times
That by itself represents a paradigm shift, but there has been another shift that has deeply penetrated the technical ranks of Crawford Broadcasting. I’m talking, of course, about the transition of broadcast infrastructure to IT. Like the proverbial frog sitting happily in the slowly heating pot of water, this transition crept up on us over the past couple of decades. Some might say that it started with a shift to digital audio (AES), but in actuality it started before that, when the first computer was installed in a radio station. Since then, what has become known collectively as information technology or “IT” has become more and more pervasive, like some kind of invasive species taking over an ecosystem with roots and offshoots everywhere.
Don’t get me wrong – this isn’t a bad thing. It’s anything but. That said, it has presented certain challenges, particularly for “senior” folks like me. We’ve had to learn an entirely new way of doing things and an entirely new (to us) technology with its own set of rules and standards, all while that technology along with its rules and standards continues to evolve. Talk about your moving targets!
Crawford’s infrastructure
Today, at this great company, all our studio infrastructures are AoIP. If there is an analog or even AES wire to be found, it’s pretty short and in sparse company. Our “rack rooms” or engineering spaces are now “server rooms.” Those big bundles of audio, AES and multi-conductor cables are gone, replaced with much smaller bundles of Ethernet cabling. In many of our facilities, fiber-optic cables are present, usually carrying data to and from rooftop- or tower-mounted microwave data links.
Transmitter sites are fully bidirectionally connected to the studios. Transmitters and just about all other equipment have network interfaces and offer both direct GUI (web) interfaces and SNMP control/monitoring. Even our phone systems, office and on-air, are fully digital, with our on-air phone systems running in containers on file servers, completely virtualized. And more and more elements of broadcast infrastructure are becoming virtualized.
While I mostly fly a desk these days, I have long spent a good bit of time doing developmental work, not dreaming up new technologies but finding ways to employ existing technologies in new (to us) ways in our broadcast facilities, and I continue to do that both personally and through various “wizards” within our company with specialized knowledge in different areas.
Chicago microwaves
Recently, we commissioned a new 11 GHz microwave data link from our Lansing, Ill., tower site on the southeast side of Chicago to the WYCA(FM) Beecher, Ill., transmitter site. This isn’t a long path, around 18 miles, and it is the last of our local Chicago market sites to get such a link. We have an 18 GHz link from our studio in Hammond to Lansing, some four air miles plus or minus, and we have plenty of capacity on that link for both Lansing (WSRB(FM) main and WPWX(FM) offsite aux) and Beecher (WYCA).
The trouble is, Rick Sewell, our engineer in the market, has for some time had that 18 GHz Hammond-Lansing link in exclusive use for Wheatnet, using a blade at the Lansing site for WSRB and WPWX audio. He has been using an unlicensed 802.11 5.7 GHz link for other Lansing site traffic, and that unlicensed link does not have the capacity or reliability to carry traffic for both Lansing and Beecher. We were seeing audio dropouts on the Beecher Tieline codec from the outset over the new 11 GHz link. Rick correctly concluded that the trouble was upstream on the unlicensed link and not on the new licensed 11 GHz link.
My challenge, then, was to find a way to run both Wheatnet and other site traffic over the single 18 GHz link from Hammond to Lansing. I knew there was a way to do that while keeping the two networks and their traffic separate, and I suspected it would involve VLANs.
VLAN wizardry
Many years ago, Art Reis told me that the mark of a true wizard was knowing who all the other wizards are. He was right, and I know a few wizards, several of whom work for this great company. One, however, is Steve Solton of Convergence Solutions, and I ran by him the gist of what I needed to do, and he immediately knew what was required and how to make it happen.
We purchased a pair of Zyxel managed switches, and with some experimentation, I was able to create two separate VLANs, one for Wheatnet and one for everything else. I was then able to trunk those through a Cambium link on the bench and separate them out on the other end. On the “studio” end, I connected the Wheatnet VLAN port to the Wheatstone switch, and I connected the other VLAN to the Zetta network. On the “transmitter” end, I connected a blade to the Wheatnet VLAN port and a computer to the Zetta VLAN port.
I could route to and pass audio through the blade with no issues, and I was able to simultaneously run traffic through the Zetta VLAN. I was also able on the native VLAN (VLAN1) connect to the Cambium GUI on each end with no issues. I could not see any of the Wheatstone multicast traffic on the Zetta side nor any of the Zetta traffic on the Wheatstone side.
After labeling everything up, I shipped the switches to Rick in Chicago. He got them installed on the 18 GHz link between the Hammond studio and the Lansing transmitter site, and everything worked like the proverbial hose! He had it running in just minutes.
Prior to this little exercise, I lived in fear of VLANs. I didn’t understand them and saw little application in our infrastructure. I learned a great deal in the process of configuring the Zyxel switches, and now I’m a VLAN believer!
That’s pretty much the way it’s been with me and all technology since, oh, 1978 or so (when I graduated engineering school). Learn by doing, then embrace the technology.
This article appeared in the Local Oscillator, the corporate engineering newsletter of Crawford Media Group. Find past issues at https://crawfordmediagroup.net/crawford-engineering/.
