[EAS] Yesterday's CAP RWT

[Dave Turnmire]

On 10/14/2012 3:13 PM, Mike McCarthy wrote:
> ..
> On 10/14/2012 2:50 PM, David Turnmire wrote:
>> On 10/14/2012 8:52 AM, Mike McCarthy wrote:
>>> David,
>>>
>>> Best practices would recommend stations only forward what they believe
>>> are relevant to their listeners and per the state and any local plan. No
>>> more.  Doing so only creates clutter and increases the "cry wolf" effect.
>>>
>> Not as a practical matter.  The fact that an Idaho station's box is
>> configured to forward a Hurricane or Tsunami warning doesn't add to the
>> clutter... we aren't going to get one of those anyway.  Likewise with
>> ADR, NIC, NPT, and NMN (at least so far).  We can even configure our
>> boxes to forward weather Watches (as opposed to Warnings), even though
>> they are NOT authorized in our state plan... and there will still be no
>> clutter since our NOAA offices aren't going to originate those anyway
>> based upon THEIR policy.  Maybe weather alerts are different in your
>> state, but that is how it is here.
> What in the world are you referring?  All classic severe weather watches
> are EAS/SAME encoded regardless of location.  I was in Sand Point, Id.
> and later Kalispell and Columbia Falls, Mt. earlier this summer on
> vacation and we had SAME alerted watches at those locations. While
> Columbia Falls (Flathead Co.) is covered by Missoula's WFO, Sand Point
> is covered by the Spokane WFO. They're both under Western Region NWS.
> And more broadly, national NWS policy.  So your comment about NWS not
> sending TOW and SVW's makes no sense Dave.
>
Well, I'm not intimately familiar with NWS practices outside of East 
Idaho.  I have never known the details of what they are doing in this 
regard and my primary contact in their local office isn't particularly 
familiar with the technology issues.  All I know is that we definitively 
are NOT receiving SAME encoded Watches here... with the exception of the 
occasional Avalanche Watch (the only permissible Watch alert in our 
state plan).  Perhaps they simply use their 1050 Hz tone and don't use 
the SAME encoding for those particular alerts.

An experience awhile back serves to emphasize that point.  I had 
temporarily configured by EAS box to poll NOAA's CAP server to see how 
that worked.  It was instructive on multiple points, including: 1/  All 
of a sudden I found my self getting a bunch of Watch alerts in my log... 
when I did NOT get a corresponding alert via their local NWR, 2/ Even 
amongst their warnings, there was occasionally some warnings on their 
CAP server that were NOT on NWR... at least not SAME encoded.    And 3/ 
The text they sent to their CAP server was NOT TTS friendly!  Struck me 
as odd given their history of using TTS on NWR.  But apparently the feed 
to their CAP server involves different text than to their NWR TTS 
engine.  In any event, it wasn't pretty.  And before I shut that 
experiment down, some of those warning alerts made it to my air space 
since there wasn't a corresponding NWR version (which arrives sooner if 
present)... and were largely unintelligible due to the poor text formatting.

In any event, it doesn't materially change my bigger point.  Having your 
box configured to forward alerts that you have virtually zero chance of 
receiving is hardly going to add to the "clutter".  And if a broadcaster 
(or cable company) configuring their box looks at the event codes and 
doesn't know what one means, they may well figure it is safer to forward 
than not to forward.  Or they could equally easily decide that if they 
haven't heard of it, it must not be important, so they can chose NOT to 
forward it.  In short, absent clarity on what event codes mean and 
whether they should be forwarded, it is, IMHO, crazy to make assumptions 
about what is happening "out there".

Dave