Re: [gpsd-dev] GPS week wraparound

[Magnus Danielson]

Hi,

On 09/27/2013 12:08 PM, Harlan Stenn wrote:
> Adding Magnus to the thread.
Thank you Harlan. Harlan have been kind to forward email messages to me,
and since I so far is not on the email list, I would appreciate if you
keep me on the CC for this thread (to save Harlan the hassle of doing
manual email forwarding).
> H
> --
> "Eric S. Raymond" writes:
>> Harlan Stenn <address@hidden>:
>>> OK.  Does GPSD address this problem?  I'm thinking that the NTP GPS
>>> refclocks should handle this the same way GPSD does.
>> From the header of timebase.c:
>>
>> All of gpsd's assumptions about time and GPS time reporting live in this file
>> .
>>
>> This is a work in progress.  Currently GPSD requires that the host system
>> clock be accurate to within one second.  We are attempting to relax this
>> to "accurate within one GPS rollover period" for receivers reporting
>> GPS week+TOW.
The GPS week issue is typically sorted out, if only the user can set the
date... like a year or so.
>> Date and time in GPS is represented as number of weeks from the start
>> of zero second of 6 January 1980, plus number of seconds into the
>> week.  GPS time is not leap-second corrected, though satellites also
>> broadcast a current leap-second correction which is updated on
>> six-month boundaries according to rotational bulletins issued by the
>> International Earth Rotation and Reference Systems Service (IERS).
>>
>> The leap-second correction is only included in the satellite subframre
>> broadcast, roughly once ever 20 minutes.  While the satellites do
>> notify GPSes of upcoming leap-seconds, this notification is not
>> necessarily processed correctly on consumer-grade devices, and will
>> not be available at all when a GPS receiver has just
>> cold-booted. Thus, UTC time reported from NMEA devices may be slightly
>> inaccurate between a cold boot or leap second and the following
>> subframe broadcast.
>>
>> GPS date and time are subject to a rollover problem in the 10-bit week
>> number counter, which will re-zero every 1024 weeks (roughly every 20
>> years). The last rollover (and the first since GPS went live in 1980)
>> was 0000 22 August 1999; the next would fall in 2019, but plans are
>> afoot to upgrade the satellite counters to 13 bits; this will delay
>> the next rollover until 2173.
Notice that many GPS clocks have intentionally shifted wrap-arounds,
with offset such as 500 and 512 been used.
Also note that the UTC-GPS time difference is set and kept in GPS time,
with wrapping, so a GPS receiver can correctly correct for UTC-GPS
difference even when it fails to "nail" the year.
>> For accurate time reporting, therefore, a GPS requires a supplemental
>> time references sufficient to identify the current rollover period,
>> e.g. accurate to within 512 weeks.  Many NMEA GPSes have a wired-in
>> assumption about the UTC time of the last rollover and will thus report
>> incorrect times outside the rollover period they were designed in.
Do they handle skewed roll-over? The offset can be arbitrary.
>> These conditions leave gpsd in a serious hole.  Actually there are several
>> interrelated problems:
>>
>> 1) Every NMEA device has some assumption about base epoch (date of
>> last rollover) that we don't have access to.  Thus, there's no way to
>> check whether a rollover the device wasn't prepared for has occurred
>> before gpsd startup time (making the reported UTC date invalid)
>> without some other time source.  (Some NMEA devices may keep a
>> rollover count in RAM and avoid the problem; we can't tell when that's
>> happening, either.)
>>
>> 2) Many NMEA devices - in fact, all that don't report ZDA - never tell
>> us what century they think it is. Those that do report century are
>> still subject to rollover problems. We need an external time reference
>> for this, too.
>>
>> 3) Supposing we're looking at a binary protocol that returns week/tow,
>> we can't know which rollover period we're in without an external time
>> source.
>>
>> 4) Only one external time source, the host system clock, is reliably
>> available.
>>
>> 5) Another source *may* be available - the GPS leap second count, if we can
>> get the device to report it. The latter is not a given; SiRFs before
>> firmware rev 2.3.2 don't report it unless special subframe data reporting
>> is enabled, which requires 38400bps. Evermore GPSes can't be made to
>> report it at all.
It's been tried and it is not very reliable if done with the wrong model.
>>
>> Conclusion: if the system clock isn't accurate enough that we can deduce
>> what rollover period we're in, we're utterly hosed. Furthermore, if it's
>> not accurate to within a second and only NMEA devices are reporting,
>> we don't know what century it is!
>>
>> Therefore, we must assume the system clock is reliable.
Which means, we must assume that the system clock is about right, but
with some basic assumption like correct day should be enough to resolve
the rest. You can't expect the CMOS clock to be accurate to within a
second for longer power-down periods, but it will keep you fairly close.
You do want to keep it reasonably updated on a regular basis such that
the guess error range becomes smaller, but it should not be needed, and
we must handle wrist-watch and manual settings which does not
necessarily achieve accuracy within a second either.

Cheers,
Magnus