Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Sage Details How ENDECs Responded

Why various stations heard various things

The manner in which various models of radio station EAS equipment acted during the national test is a topic of ongoing discussion.

RW earlier reported the observations of Sage Alerting Systems President Harold Price. He also has been answering questions directly from Sage users.

Here’s a copy of information Price provided to engineers including Cris Alexander, DOE for Crawford Broadcasting and an RW contributor.

Price delves further into what Sage boxes did and what local stations saw as a result in the national test:

The oddities were caused by the second set of headers that arrived in the EAN message. This caused the ENDECs to end the alert early, in various ways depending on the quality of the audio received.

Here is my current understanding of what went on, and why some stations heard or did different things. As always, my comments apply to the Sage ENDEC only.

The Sage main goals in EAN handling are:

1) try hard to get it on the air.
2) try hard to end with an EOM if something goes wrong.

I’m happy that this seems to have been the result in most cases, and ENDECs played the audio that was received, up to the second set of headers.

Getting the second set of headers send from high up the chain was unexpected, however.

If the ENDEC receives a second set of headers on a monitor input that is currently in an alert, it assumes that it missed the EOM from a previous alert (see #2 above), and starts the process of ending that previous alert.

That second set of headers, if it was decodable by the receiving station, terminates the audio “early”; the recorder is restarted, causing the output to mute. It only takes one properly formatted header to do this. If you decoded one of the second group of headers, your audio appeared to mute for several seconds.

Only one header is sufficient to cause the input audio to mute, but not sufficient to detect a valid new alert. If you decoded only one of the second set of headers, you did not get a log of that alert — because it takes two headers to be a valid alert. If you decoded two, the alert was logged.

This explains reports that the audio was muted, but the second group of headers was not logged. The quality was probably only good enough for one header to be decoded in many cases — because the audio was at least second-generation by that time. Typically, you only get first-generation data tones.

If the audio wasn’t good enough to decode any of the headers, then they were recorded by your ENDEC and played out as part of the alert.

The further down the chain you were, the less chance you had to detect the second set of headers, they were either stripped because the upstream station had removed them, or they were now third-generation and even less likely to be decoded. You either heard and relayed the first few seconds of the script and some silence, or all the script with the extra headers (and attention tones).

In almost all cases, after a few seconds of silence, your ENDEC sent an EOM on its own, and put your station back on the air. There are reports of stations staying in the alert mode longer, I don’t know yet if any of those were Sage ENDECs.

If the second set of headers hadn’t been there, the test would have gone pretty well. With the exception of that issue (ok, that’s a big exception) the test did go well. Many stations received, and relayed the alert.