[EAS] Posting on SBE list

[Richard Rudman]

This was posted on the SBE list by Harold Price  in response to the current thread. It explains what was observed at many locations.

Richard Rudman

===========

Apologies if this duplicates to some extent what I've sent on this forum previously tonight.

The oddities were caused by the 2nd 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 is:
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 2nd set of headers send from high up the chain was unexpected, however.

If the ENDEC receives a 2nd 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 2nd 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 2nd 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 2nd 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 2nd 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 2nd 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 2nd 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 2nd 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.

Regards,
Harold