[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