[EAS] BLU Alert Comments.

[Sean Donelan]

On Fri, 4 Aug 2017, Ed Czarnecki wrote:
> Not sure if you were being ironic, but part of this has existed for quite a
> while - for example on the DASDEC,  the EAS-Net communications protocol
> software provides data and audio transmission over a TCP/IP network.
> EAS-net is supported by a wide range of automation systems for store and
> forward (within the allowable transmission time) including WideOrbit, RCS
> NexGen, the Utah Scientific MC-40/400/4000 master control series, etc.

Also thanks to our cable labs & SCTE cohorts, I believe all the EAS 
manufacturers within the last 15 years or so, have TCP/FTP interfaces with 
various automation middleware.  Its also why you will hear loud cursing 
between the NCTA and NAB about how "simple" something is.

Its not always "simple." Even a simple change with middleware can be a 
nightmare. But, with a good relationship between your EAS vendor and your 
middleware/automation vendor, it works very nicely.

> However, the "waterfowl flatulence" is something we're stuck with, for now.

For mandatory (EAN/NPT/RMT/RWT) messages; yep you are stuck with the 
EAS data bursts and attention signal until FCC changes.

However, for optional messages, just because you received it as EAS 
doesn't mean you need to forward the message with EAS. You could do the 
same thing as many commercial weather alert systems. Do your own program 
insert without using the EAS data burst or attention signal. In the old 
days, the news announcer could just read it as part of a news break (no 
waterfowl noises required).

However, talk to your communications lawyer. EAS forwarding has some 
liability protection which you may loose with a program insert instead of 
EAS. Your news announcer probably wouldn't read a message about zombies 
on the air, but your automation system would.

In theory, the middleware could handle each type of optional EAS message 
differently.  I don't know radio automation as well as I know IPTV 
middleware.