[EAS] Yesterday's CAP RWT

[Dave Turnmire]

On 10/11/2012 6:34 PM, Mike McCarthy wrote:
> On 10/11/2012 3:23 PM, Dave Turnmire wrote:
>> The difficulty I have with NMN, ADR, or any of those types of event codes... is that their meaning is not well understood within the broadcast community, nor is their any generally agreed upon guidance on critical issues like whether they should be forwarded.
> Dave,
>
> I'm not sure who you work with, but I know of no station or cable entity who "forwards everything". It's equally disruptive and counter productive as airing nothing.
Well, there are no doubt members of this list who live in cities with a 
greater population that my entire state, so that tends to change 
things.  In MY state, the non-weather non-test alerts are less than one 
per month!  Even the weather alerts aren't all that frequent except for 
in "SVR season".  So, in that context, it makes perfect sense for a busy 
engineer to configure their box to log RWTs and forward everything else.

And lets not forget that there is wide variation in the flexibility that 
EAS boxes allow.  When I was using a SAGE I could create filters for 
almost any combination alert criteria and specify immediate forwarding, 
logging, delayed forwarding, etc and all could be done for different 
combinations of counties.  About the only criteria I couldn't use 
(unfortunately) was filter based upon input source.  When we upgraded 
for CAP and got a different product, then, aside from RWTs, my only 
choice was to forward or not forward alerts.  None of the flexibility I 
was used to with the SAGE is available to me now.  Grrrr!  So... to use 
one example... before I could deal with the excesses of "SVR season" by 
specifying that I'd forward all the other alerts (except RWT) for my 
entire coverage area.  But in the specific case of the SVR, I'd only 
forward it for my two most populated counties.  With my new box, I don't 
have that freedom, so the lesser of evils was to eliminate forwarding of 
the SVR entirely.  Not a great choice IMHO.

> ...
>
> What hasn't changed is the fact everything a station receives needs to be logged regardless of message type.  The use of a "heads-up" message such as the NMN sent to FIPS 00000 would at least provide a measure of relief to know whether they were supposed to receive an official test for their area or state. Anyoneoperating under Part 11 and their respective logging rules would welcome some level of supplemental accounting to meet their obligations of determining a received message failure.
>
> Additionally, a very effective employment of the NMN message is to send the advisory message to to FIPS 00000 and not xx000 x 72.  Not only does that test the the NMN, it also tests the only FIPS code used for an Presidential EAN/EAT or national level message outside of a EAN/EAT. Should one not receive that message, then that's a clear sign something is wrong somewhere.
>
As mentioned in other posts, the availability to us of FIPS 00000 is a 
myth.  I really really wish we COULD use it.  But until the 
rules/standards are changed and the EAS decoders (and related products) 
are either updated or verified to be compliant with its use... it isn't 
available to us.  Knowing the types of shortcuts that software writers 
like to use, I wouldn't be surprised if in some cases 00000 (or 99999) 
were used for some other convenient (to them) internal purpose and we'd 
break the system if we tried to use it.  Hopefully not, but you know 
what the say about the word ASSUME...

Dave