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

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Sat Aug 17 08:30:07 UTC 2013


David Taylor wrote:
> On 16/08/2013 08:12, Magnus Danielson wrote:
>> Using ICD-GPS-200D gives a fair idea of what the older GPS receivers was
>> designed to meet.
>>
>> In these documents, the "gears" of GPS is explained such that you should
>> be able to implement a correctly working receiver (in principle). There
>> are a handful of technical details outside of this spec you need to
>> figure out too, but there are good books for that.
[snip]
>
> Yes, all my receivers are very simple, consumer-level ones.  Sometimes I
> see as low as 2m "location accuracy" on the GPS 60 CSx, more likely 3m
> when walking.
>
> 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
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list