[ntp:questions] Start of new GPS 1024 week epoch

David Taylor david-taylor at blueyonder.co.uk.invalid
Sat Aug 17 16:02:38 UTC 2013


On 17/08/2013 09:30, Terje Mathisen wrote:
> David Taylor wrote:
[]
>> Thanks for the pointers to the documents.  A pity that they haven't been
>> able to find two or three spare bits to reduce the 1024 week ambiguity
>> to nearer a half-century or even 100 years.  Oh, well!
>
> That would be even worse:
>
> Exceptional events like the 10-bit week rollover needs to happen often
> enough that every programmer is forced to write code to handle them
> correctly, or it should not happen at all!
>
> I.e. a fault-tolerant server setup is only fault-tolerant if you are
> comfortable doing monthly fire drills where you pull the power cord (or
> network cable(s)) from either half.
>
> For GPS 19+ years was probably intended to be long enough that every
> given receiver would only live to see a single epoch, meaning that a
> simple test against the firmware generation time would suffice, right?
>
> Well, now we've seen a lot of timing receivers that just keep on
> working, and that 19+ year range turned out to be not quite long enough.
>
> If this has happened every year or so (i.e. a 64-week rollover), then
> every GS would have had some method to enter the current epoch, and a
> way to remember it across reboots.
>
> Personally I think the (Trimble?) hack to use the TAI-UTC offset field
> as an epoch guess table index is pretty nice:
>
> As long as the offset keeps increasing this will suffice to handle at
> least one or two epoch rollovers.
>
> OTOH, the firmware timestamp method I outlined above will work perfectly
> as long as (a) somebody is still willing to generate new firmware
> versions and (b) you still have some machine with compatible
> hardware/software to allow you to load it onto the GPS.
>
> Combined remote antenna/GPS receivers with an RS422 or similar
> connection to an NTP server requires that firmware update capability to
> be included in the NTP box. :-(
>
> Terje

Thanks for your thoughts, Terje.

Using a 12-bit (or even 16-bit) field to send the current year would be 
a preferable solution - at least until they start messing with 
leap-seconds and change the whole time scale.  But I take your point - 
once every 19 years it will be remembered a lot more easily than once 
every 76 years.

Having a multiplicity of different GPS sources from different 
manufacturers may at least improve the chance of the problem being spotted.
-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list