[EAS] EAS time stamp usage

[David Turnmire]

I have a lot of hardware in my TV station, EAS and otherwise, with NTP 
support.  In general, that is great... because otherwise it would be 
unpractical to keep all of their clocks from drifting off considerably 
(thus screwing up logs if nothing else).  I have seen a number of 
implementation issues.  Some are sufficiently picky about the NTP server 
that they don't work well with Windows time servers, which is often the 
simplest/cheapest way to keep consistent time throughout the plant, 
especially if you have a windows domain system.  Often they only allow 
IP addresses rather than host names, which creates its own set of 
practical difficulties.  Often they only allow a single NTP server... 
which is even a bigger problem if they only support IP addresses.  
Sometimes they give up pretty quickly when they can't reach an NTP 
server... and never try again until rebooted, etc.  All that concerns 
UTC time.  Getting LOCAL time right is another issue... especially as it 
regards daylight savings.

I wouldn't think it should be that hard to resolve all of the above... 
some vendors do.  And for any integrated CAP compliant EAS boxes, that 
shouldn't be a cost issue since I believe they are already dependent on 
the internet and often have Linux or similar under the hood anyway.   
(And the number of times we have to use the phrase "except for converter 
box applications" should be an indicator of the problems with their 
use).  I'd also like a user friendly way to specify how large a time 
error that they should correct for, to minimize potential for NTP server 
problems affecting you.

IMHO, a BIG problem... especially with time dependent devices like EAS 
boxes, is that IF/WHEN there is a problem with syncing the clock... 
there is little or nothing to draw your attention to this fact other 
than you noticing the time is off... which normally means it is off 
quite a bit by that point.  Burying this info in some error log or the 
like that the average user doesn't review routinely (or perhaps 
understand) isn't very helpful.  Better would be a warning at the time 
you login into the web interface, or a blinking light on the front of 
the device to indicate an error condition.  Or a note at the top of the 
automatically emailed reports.  Any number of notification methods could 
be done.

All that being said... I wonder if we aren't over stating the problems 
with EAS clocks during emergency conditions.  For one thing, in general, 
EAS serves the role of providing a quick, early warning that there is an 
impending emergency or one that is just occurring.  After everyone knows 
about the emergency, the normal news coverage mechanisms take over.  
Thus, the time for the clock accuracy to be maintained systematically is 
BEFORE the emergency.  Once the emergency takes place, even if it 
affects infrastructure such as internet, GPS (more likely the earthbound 
antenna than the space born satellite), etc, the native clock within the 
EAS equipment should stay within a minute of it's pre-emergency accuracy 
for at least a day... maybe longer.  And generally you aren't sending 
out additional EAS alerts after that.

Even in the situation that you are, IF the EAS box clock was accurate to 
begin with, it should take awhile for it to drift enough to matter to 
EAS.  At least for boxes that were designed intelligently to begin 
with.  IMHO, as others have suggested, the box should be pretty tolerant 
of alerts arriving "before they were sent" since that is likely a clock 
tolerance issue.  Alerts should be relayed as quickly after reception as 
the technology allows, except as dictated by user.  And it takes at 
least 15 minutes for an EAS event to "expire", so that is a pretty wide 
window.  The main issue with the latter is if there are too many "hops" 
the EAS signal has to pass through, with too much delay in each (either 
as configured by user or by nature of design).  But the latter issue is 
more directly solved by minimizing the relays, which I think we all wish 
to do.

As for grabbing a "cold spare" off the shelf... and setting the clock... 
are we REALLY saying that even with an infrastructure affecting 
emergency... we can't find the correct time (within a minute or two)?  
In a broadcast station full of computers, cell phone clocks, wall 
clocks, etc?  Believe it or not... some of us still wear watches.  Most 
of us are broadcasters.   And as long as I have been a broadcaster, time 
mattered.  By law, a TV station has to broadcast the time within ONE 
second accuracy.  That's a little tricky if you rely on Windows 
infrastructure, but keeping within two or three seconds isn't.  In my 
early broadcast days, my watch was seldom off more than a few seconds 
because I couldn't do my job right if it was.  Times and my 
responsibilities have changed, but my watch is still never off a 
minute.  In any event, if you are thinking about EAS in the middle of 
that emergency enough to be looking for a cold spare, you're thinking 
about it enough that if all else fails, you can find a ham operator to 
get you WWV time.

So... lets work on putting together some industry guidelines (like 
others, I'd like to keep this out of the regulatory arena) for NTP 
implementation.  And have guidelines for how to handle alerts arriving 
before the "JJJHHMM" time and clarify how quickly the alert should be 
relayed and whether there it should start being transmitted before it is 
fully received.  But IMHO, there isn't a need to make those guidelines 
hard to implement or expensive. Some vendors already do pretty well and 
need only a little "tweaking".

Dave