[LEAPSECS] DCF 77

[Warner Losh]

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