Tom Van Baak wrote:
when all is said and done). A 12.5 minute down time means your
annual reliability can only be 4 9's, not 5 9's... This is why
many receivers remember the last UTC offset values and warm start
with them if they have only been off a short period of time...
Warner
User code can usually handle being told by a GPS receiver that "UTC
is not known yet; use GPS time instead". But when a GPS receiver
says "sorry, by the way, all the UTC time stamps
I've sent you in the past quarter hour were off by one second", that
might be a little more trouble to deal with.
Could somebody comment on the reliability of GPS receivers to deliver
GPS time itself?
It is clearly aberrant design for any system to ever lie about a
return value. This is why error handling exists. There are any
number of quite desirable reasons a specific model of GPS receiver
might be designed to behave idiosyncratically. If there is no
separate channel to convey errors properly, then it should at least
return a non-legal value (-1 or such) pending this 12.5 minute start-
up interval. The three behavioral issues (choice of timescale,
potentially lengthy initialization procedure, proper error handling)
are orthogonal.
That said, client applications often have to deal with less than
perfect hardware or software components. In this case it sounds like
the app (or a system like NTP) would be wise to manage restarts by
marking a restarting receiver as invalid for 12.5 minutes (or until
some other condition is met). I'm sure I'm about to hear why this is
a naive statement :-)
However, is it a true assertion that currently deployed GPS receivers
return GPS time significantly more reliably (all those 9's) than they
do UTC? (Assuming a particular model supports both?)
It's hard to see this as supporting a position that "Only UTC can be
disseminated"...
Rob
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
