EAS Issue

[BigRed]

I'm curious if anyone has had any experience running EAS "tones" from a SAGE unit (or any other brand of EAS encoder for that matter) through a Telos AXIA system. If so did you have any issues with the "tones" making it through the system intact?

Reason I ask is that I have a small station group that had their system configured that way by others. (Seems to me like a bad way to handle EAS, but what do I know?) The EAS "tones" seem to make it through the system in that they can be heard on air. But EAS decoders (multiple SAGE units, and possibly other brands) can't seem to decode them "off air" after they pass through the AXIA system. It's been that way since the AXIA system was installed. No issue decoding the EAS "tones" until they hit the xNode input unit and the level into the xNode looks to be OK.

Just wanted to see if anyone has any easy suggestions before I re-wire the system in a more conventional manner.

Thanks much for your input.

[Shane]

Just wanted to see if anyone has any easy suggestions before I re-wire the system in a more conventional manner.

Re-wire the system in a more conventional manner.

If the place runs unattended at any time, having EAS depend upon someone remembering to leave the pot up is asking for trouble.

[BigRed]

Thanks for the reply Shane but I didn't say anything about having to have a "pot" open on a "control surface" to make the mess work. The set-up appears to be more of a virtual switcher situation where the AXIA system switches away from the Program source for a particular station and to the EAS source when it gets a GPIO input for that station from the SAGE box via a third-party multi-station switcher interface. (Seems like an extra layer of complexity/possible failure to me; but again, what do I know?) So the worry along those lines is more of a computer crash being able to cripple the EAS system than a forgetful jock failing to "pot up" a source before heading out for Miller time. (And that's another reason I'm leaning towards the more conventional installation scenario. (My reluctance to do that at this point is due to the "politics" of making the change; otherwise it would have already been done.)

But I am curious if anyone else has this scenario with the AXIA system (or any other digital audio system). I'd like to know if the EBS "tones" can actually make it through an AXIA system. My concern is that the "tones" seem to make it through the AXIA system but are not actually decodable. A station with a similar set-up may not even be aware of an issue unless another station is actually monitoring them with an EAS decoder downstream (another miserable flaw in the current EAS system, no self-monitoring requirements or even provisions to do so). One of this group's stations is an LP2 and someone assigned to monitor them called attention to the issue (actually several stations). Otherwise they would have been none the wiser. (This was so much simpler back in the days of EBS when all we had to due was interrupt the carrier three times at 1-second intervals, )

[TPT]

With two stations and one EAS box, we use the Broadcast Tools switchers for EAS alerts. The Sage, (in this case) sends out a closure that switches a pair of 2X1 BT switchers from the program lines to the audio output of the Sage. The EOM switches the program lines back on. Only problem I've had is when no EOM was sent--stations just sat silent until the 2 minute time-out.

[radio_guru]

In our group, the EAS is after all switching regardless of whether we're operating in AoIP or conventional. Insertion is after the delay, all pre-processing, emergency bypass switches, everything. We use a pair of TFT 940 multi-station insertion units for feeding four stations just before each station's PPM encoders and subsequent air chains. Given the 940 is simply a rack of relays, we have one set for AES and the other for analog. It's a slam dunk to create your own if needed...just be sure to use gold flashed contacts.

I see no real reason to send the program back into the AoIP system at that point. It's simply a bunch of inputs and outputs tied up and can be a big rules violation if it's switches out the EAS for any reason. For a failsafe/recovery, we install a secondary switch/relay to drop/kill the closure command going to the 940's.

Seriously rethink the manner in which this group is configured.....

RG

[BigRed]

In our group, the EAS is after all switching regardless of whether we're operating in AoIP or conventional. Insertion is after the delay, all pre-processing, emergency bypass switches, everything. We use a pair of TFT 940 multi-station insertion units for feeding four stations just before each station's PPM encoders and subsequent air chains. Given the 940 is simply a rack of relays, we have one set for AES and the other for analog. It's a slam dunk to create your own if needed...just be sure to use gold flashed contacts.

I see no real reason to send the program back into the AoIP system at that point. It's simply a bunch of inputs and outputs tied up and can be a big rules violation if it's switches out the EAS for any reason. For a failsafe/recovery, we install a secondary switch/relay to drop/kill the closure command going to the 940's.

Seriously rethink the manner in which this group is configured.....

RG

You're a keen observer of the painfully obvious RG.

If changing this "configuration" was not a political hot potato because it was done "by others" (as I stated above) it would already have been changed back to the more conventional method of switching between program and EAS encoder. And it would be done with the dedicated, stand-alone switching equipment which is on site and currently being used to provide the GPIO contact closures to the AXIA equipment. (There's a new DM Engineering box, complete with relays with those coveted bifurcated gold-flashed contacts, being used for that very purpose at this site; no need to reinvent the wheel.) That's the way it was done successfully BEFORE the AXIA system was installed, except with SAGE's version of the relay box, times two. [I note that the SAGE EAS box (as well as the Monroe EAS box) has the ability to output a serial data stream that will control an external switcher, or switchers, for that very purpose, and that works quite well.]

But my question was not about how to install a "conventional" EAS interface; been there, done that, a number of times. I was asking if anyone has successfully implemented this little trick using the switching within the AXIA system and having the EAS signaling making it through that pathway intact. At this point I have serious doubts that has ever been done as it adds an extra layer of complexity, additional potential failure points and probable distortion to the EAS signaling tones; makes no sense to me either. But if it has been done successfully I would be curious as to how the AXIA was configured as the person that installed this system doesn't seem to be aware of those pitfalls. And if it's been tried and failed that would be useful information to take to "management" to justify putting things back the way they should be.

[Shane]

I got nothing except to ask if you've talked to Kirk Harnack.

[dbuckley]

The EAS "tones" seem to make it through the system in that they can be heard on air. But EAS decoders (multiple SAGE units, and possibly other brands) can't seem to decode them "off air" after they pass through the AXIA system.

This is a long-shot, but I wonder if it is a similar issue to trying to fax across a VoIP system, which just doesn't work, which resulted in T.38 encoding system for fax over VoIP.

It's a long-shot because VoIP systems tend to mangle data but sound OK, especially given the ear is much more forgiving than a modem. But an AoIP system should - in theory - be lossless and perfect.

[BigRed]

I got nothing except to ask if you've talked to Kirk Harnack.

No, I've only talked to someone in support. But that's a good suggestion if this problem does end up being an AXIA issue. Either he or Marty.

But recent information has me thinking that while it is a problem with the system architecture it may not be an AXIA issue. I'll elaborate in a following post.

[BigRed]

The EAS "tones" seem to make it through the system in that they can be heard on air. But EAS decoders (multiple SAGE units, and possibly other brands) can't seem to decode them "off air" after they pass through the AXIA system.

This is a long-shot, but I wonder if it is a similar issue to trying to fax across a VoIP system, which just doesn't work, which resulted in T.38 encoding system for fax over VoIP.

It's a long-shot because VoIP systems tend to mangle data but sound OK, especially given the ear is much more forgiving than a modem. But an AoIP system should - in theory - be lossless and perfect.

Great thought. And maybe not as long a shot as you think, except it appears it may not be the AXIA equipment but rather the Nielsen PPM encoders. Here's a link to a Crawford Broadcasting engineering newsletter that discusses the possible issue. Check out the second page, right-hand column starting about 1/2 way down . . .
https://crawfordbroadcasting.com/Local_ ... llator.pdf

[TPT]

The PPM encoder runs a series of tones--somewhere in between 2~4 khz--which are embedded in dense audio (which explains why news/talk and smooth jazz stations don't do well in PPM markets). Speculating--it may be the masking algorithm which allows the hiding of the tones in dense music is mangling the EAS tones, or the mixing of the PPM tones makes the EAS alert harder to decode.

I monitor two NWS stations, before the weather service built a new site, one or both would fade almost into the noise--but I could still decode alerts. But then the background was only random white noise--not in band tones like PPM.

[dbuckley]

Here's a link to a Crawford Broadcasting engineering newsletter that discusses the possible issue.

Does sound suspiciously like what you're suffering, doesn't it?

If the PPM encoders were screwing over EAS tones, every station in the land would be screaming, but they're not (I presume...?) so it must be something about a combination of something with the PPM encoder. I'm going to point to the processing settings, as that does differ between stations, and suggest that some processing choices cause EAS and PPM to get confused, confuzzled, masked, or some similar artifact. It's a bit brutal, but I'd suggest you try an alternative processing setting, something very vanilla, for an EAS test and see if the tones come through OK.

[BigRed]

Here's a link to a Crawford Broadcasting engineering newsletter that discusses the possible issue.

Does sound suspiciously like what you're suffering, doesn't it?

If the PPM encoders were screwing over EAS tones, every station in the land would be screaming, but they're not (I presume...?) so it must be something about a combination of something with the PPM encoder. I'm going to point to the processing settings, as that does differ between stations, and suggest that some processing choices cause EAS and PPM to get confused, confuzzled, masked, or some similar artifact. It's a bit brutal, but I'd suggest you try an alternative processing setting, something very vanilla, for an EAS test and see if the tones come through OK.

No, I don't think it's an audio processing problem. That stuff hasn't changed in any way since I've been dealing with the station group and the EAS system used to work just fine. The only thing that has changed is that the EAS equipment was moved from the outputs of the respective PPM encoders to the inputs of those PPM encoders. (We could test that theory by placing the PPM encoders into "Bypass" prior to running an EAS test, and I will do that my next visit to the studio site if the "contractor" that should be responsible for the mess hasn't dealt with it by then.)

Right now it appears that (since that firmware update from Nielsen/Arbitron a while back) it's a matter of equipment placement in the audio chain. Most reasonable stations put the EAS gear at the end of the audio chain to begin with, nearest the transmitter input (or stereo generator input for FM stations) or at the input to the audio processing, downstream from the PPM encoders. So those encoders will have no effect on the EAS signaling. Prior to that Nielsen update I don't think it mattered, the PPM encoders probably passed the EAS signaling unmolested, although I don't know that for certain.

But a bit of history . . . the reason that many believe the Nielsen update was made was because of the Telos Alliance. It seems that Telos determined that the audio of some stations (or all stations according to the Telos marketing department) was actually masking the PPM data insertion causing stations to not show up in their respective DMA audience "measurements". They introduced a device (the Voltare) to "pre-process" audio being fed to the PPM encoders to minimize that masking effect. And it does seem to work for some reason.

Anyhow, that caused a LOT of consternation among the radio broadcaster (I think that there's only one left, thanks to Wall Street machinations ) and with the folks at Nielsen. So Nielsen responded with the firmware update. And that is (apparently) when the feces hit the air motivator with EAS tones passing through those PPM encoders.

And one other observation . . . unless a radio station is being monitored by another entity with a real (FCC Certificated) EAS decoder, or they're monitoring themselves (not a requirement, that costs money, so it's not gonna happen) they may never know that their EAS data isn't making it intact through their audio chain. To the ear it sounds like it's being passed but the decoders don't recognize it for some reason. So there could be a number of stations that are no longer meeting their EAS obligations and they're just not aware.

[ncradioeng]

On a similar note -

After NC installed the Comlabs satellite delivery system for the LP stations, the Sage boxes would not decode the tones coming from the Comlabs computer sound card (the other manufacturers' units worked as I recall). Recording the tones into Adobe Audition and blowing up the waveform revealed small imperfections along the slopes of the waveform. I don't know if this caused the problem, but Comlabs did something to fix it.