[EAS] Overlap/monitoring issue

David Turnmire eassbelist at cableone.net
Thu Mar 6 20:29:24 CST 2014


Thanks Sean.  Good info to know.  That sounds like in the case of RMTs, 
it may be best to routinely configure the box for something like a 3 
minute delay... at least for stations in areas where there is a 
significant chance of receiving multiple RMTs.  Fortunately for my 
state, we only have one border state where we have to worry about 
duplicate RMTs, and in that case, we coordinate things to eliminate the 
problem.  But for non test alerts... such as tornadoes, IMHO, it doesn't 
seem wise to add delays.  For some types of alerts, seconds matter.  
Plus, aside from CAP delivered alerts, it is still a daisy chain system, 
so there are already some delays built-in.

Perhaps it would be worth some discussion here on the merits of allowing 
a subsequent alert that is not a duplicate and has the same priority 
level, to be interrupt an already in process alert.  To my way of 
thinking, only a higher priority alert should be able to do that.  It 
seems to me that the odds favor a bad result rather than good if you let 
an equal priority alert trump an existing alert for no better reason 
than it is several seconds newer.  If the general consensus here is 
agreement on that point, perhaps Harold would consider a change in a 
future software release.

I concur with the suggestion that the input source be added as a filter 
option on the SAGE.  Aside from this particular example, I have run into 
other circumstances where it would be desirable.  For instance... in our 
state CAP is the primary origination method, with the legacy system used 
as backup.  But, since you get CAP messages by polling (in most cases), 
it is quite possible that you receive the alert by the legacy system 
prior to the CAP message... and thus forward it, thus missing out on the 
superior audio quality of a CAP message.  We try to work around that a 
bit by adding a minute delay on the legacy system, but that doesn't 
always work... and as mentioned above, I'm not too fond of deliberate 
delays.

Dave



More information about the EAS mailing list