On 12/24/2010 03:35, Magnus Danielson wrote:
On 12/24/2010 06:01 AM, Warner Losh wrote:
On 12/23/2010 13:15, Magnus Danielson wrote:
On 12/23/2010 08:50 PM, Warner Losh wrote:
On 12/23/2010 12:26, Tom Van Baak wrote:
GPS's model for handling of leap seconds is better: you
get both a UTC offset and a date when the leap second
is/was to be applied. Thus it is possible for you to obtain
TAI, GPS, or UTC out of a GPS receiver. One downside
is that you have to wait up to 12.5 seconds for the leap
second information to show up, which can cause timing
issues with cold-start receivers.
Isn't it more like 12.5 minutes since the NAV data is clocked out at
only 50Hz? And I know some older M12 firmware had issues that meant
you'd have to wait 2x that long since it waited for the start of the
almanac to start getting the data, which meant if you just missed the
first bit, it waited for the whole thing to go by twice.
TAI and GPS time are always available after you acquire satellites.
Caching the last leap second value/time means that sometimes you can
start up more quickly if you assume semi-annual leap second
possibilities.
Just as the almanac info, the leap second info can be cached in the
battery backed up memory. Many GPS receivers do have the feature, but
not always is the battery installed. However, just because the
receiver has a backup battery it does not mean the leap second info is
placed there.
The cached information isn't very useful when the GPS receiver has been
off for a while. Coming up on a cold-spare GPS receiver requires that
you wait.
True, but considering that the IERS announcement comes out over 5
months in advance and that the GPS operations fairly quickly enters it
into the system, you can with some good certainty know if you may have
missed it and is affected. If you have stored away the time of last
almanac you would be able to make the decision. The weak part of this
method is that it depends on the practical routines of the GPS
maintenance and not on a written down property of GPS.
Some of our customers likely wouldn't have been able to follow the 'plug
in your GPS spares every 6 months' routine maintenance.... Good advice,
but much of the cold-spare gear is at lights-out facilities that rarely
have people go there unless there's a problem (which is why there's
redudnant hardware: buying extra hardware is cheap compared to the
round-trip to these facilties).
One could also avoid using a GPS receiver as timing source for the
first time after wakeup such that it will attain the time offset
information. It would be just another error condition for which it
should squelch it's outputs and indicate errors on the serial port.
The receiver do know it hasn't full information and can act
accordingly and we won't get fooled by it. That's how you can solve it
safely. It's booring to wait, but it is safe.
Yes. That's what we do in fact. However, the customer gets grumpy
about this because the timing signals we produce are needed more quickly
than that. There's fallback timing sources in this case, but it gets
messy (and involved writing a bunch of code).
Warner
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
