Re: [gpsd-dev] GPS week wraparound

[Magnus Danielson]

Now look who forgot to have me on the CC. The irony.

Cheers,
Magnus

On 09/27/2013 01:30 PM, Magnus Danielson wrote:
> 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