By SCOTT FYBUSH
*
In some markets, the local Bones affiliate happened to be an EAS primary station, and so that audio was heard by EAS receivers all over the market (including, yes, at the local U-Verse headend). Depending on how each receiver was set, the result was either nothing (if the box saw the timestamp on the alert and was programmed to ignore “stale” alerts) or a further retransmission of the message (if the box was programmed to assume that even an EAN with a stale date should still be relayed, because you never know if the station upstream in the chain has the time set correctly on its encoder.)
As you’d expect by now, the fingers of blame are being pointed all over the place, especially on engineering mailing lists. Should Bones or his producer have known better than to have played that audio clip, especially on a national show? Of course – and yes, there will almost inevitably be FCC fines against Bones’ flagship WSIX in Nashville and perhaps other stations that carried the show. (In NERW-land right now, Bones is heard on iHeart’s WBWL in Boston; fortunately for them, their small signal doesn’t play a big role in the region’s EAS daisy-chain, so we’ve heard no reports of the errant alert being disseminated widely.)
Will Bones lose his show over this? No, and he shouldn’t. While a FEMA alert to the engineering community on Friday afternoon urged, among other bullet points, to “socialize the implications of including EAS tones in the broadcast (§11.45 “Prohibition of false or deceptive EAS transmissions”) among the content providers and program directors,” we’d argue that there are deeper underlying flaws in the way the EAS system is designed – and until those are addressed and fixed, incidents like this one will keep happening.
A bit of background for those of you on the programming or management side: as the successor to the old Emergency Broadcasting System, EAS was designed, at least in part, as an in-band system. Under each state’s EAS plan, every station is assigned at least two other stations to monitor, and an EAS receiver is constantly listening to the incoming audio from those stations. Anything that’s transmitted as program audio on those stations can potentially trigger EAS receivers at stations downstream – and at cable systems that monitor for EAS activations, too.
That’s what happened here: a piece of audio that was never meant to do anything other than illustrate the host’s rant (Bones was unhappy that a different EAS activation had interrupted him while watching a World Series game the previous night) ended up triggering a daisy chain of stations and cable systems down the line, entirely by accident, simply because the audio included a data burst that carried the “EAN” code from almost three years earlier.
Yes, by all means there should be better education in the programming community that you simply do not play EAS audio over the air, ever. It’s a lesson Bones and his staff are learning now, and we’d bet the word is getting out pretty widely throughout iHeart and other big broadcast groups, too.
But this is hardly the first time an errant bit of EAS audio has caused problems. We’ve had incidents in recent years in which EAS data bursts have been included in movie trailers and even public service announcements. With millions of hours of audio content being created every week all over the country, we’ll have more such incidents in the future, too. Doesn’t it make sense to lock the system down at the other end, too? If EAS must include in-band data signaling, those audio bursts of data shouldn’t be able to reach the transmitter from any source other than the station’s own EAS encoder. Somewhere out there, a clever EAS equipment provider out to be able to design a box that can stop the audio of EAS data bursts from getting down the audio chain to the transmitter and causing this sort of chaos…right?
And as the next generation of EAS is developed, it’s probably time to break completely from the entire idea of in-band audio. That 2011 national test that Bones accidentally aired demonstrated that daisy-chaining audio from station to station doesn’t work well, even ignoring the telephone-link feedback problem that messed up the audio of the test in the first place. We have the capability to securely deliver audio and data directly to individual stations and to cable headends via networks that are at least as hardened as our broadcast system. Why are we still depending on delivering that audio and data over the same programming stream that brings us Bobby Bones in the Morning?
Read this week’s entire NorthEast Radio Watch column here!
THE 2025 TOWER SITE CALENDAR IS COMING VERY SOON!
The landmark 24th edition of the world-famous Tower Site Calendar is in production, and your support will determine whether it will be the final edition.
It’s been a complicated few years here, and as we finish up production of the new edition (including a cover reveal, coming later this week!), we’re considering the future of this staple of radio walls everywhere as we evaluate our workload going forward.
The proceeds from the calendar help sustain the reporting that we do on the broadcast industry here at Fybush Media, so your purchases matter a lot to us here – and if that matters to you, now’s the time to show that support with an order of the new Tower Site Calendar. (And we have the new Broadcast Historian’s Calendar for 2025 ready to ship, too. Why not order both?)
Visit the Fybush Media Store and place your order now for the next calendar, get a great discount on previous calendars, and check out our selection of books and videos, too!