[ntp:questions] Start of new GPS 1024 week epoch
"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.
> 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.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions