Re: [gpsd-dev] gpsd rolls back to 1999

[Sanjeev Gupta]

Gary, Hal, thanks for the prompt replies.

I am aware of the 19year problem; but I thought

1. compiling gpsd fresh would make it use *that* date as a pivot
2. The system time being correct *before* gpsd invocation would give it a clue

I seem to remember this being discussed in detail, lots of detail, on the list.  I sort of thought the above two safety nets were in place.

Q1: What is your recommendation?

On an ntp issue, I have these two lines:

refclock shm unit 1 prefer refid PPS flag4 1 prefer # minpoll 0 maxpoll 5
# refclock shm unit 0 refid GPS time1 0.650 flag4 1 # minpoll 1 maxpoll 5

Note I commented out the second.  I recall discussion that this would give me a top-of-second lock, but not use the GPS for a "count of seconds".  This is not happening, ntpd jumps on start to 1999.

Q2: How can I use PPS from gpsd, yet not the absolute time?

Thanks,

--
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane

On Sat, Jun 22, 2019 at 2:21 PM Hal Murray <address@hidden> wrote:

> I have a Surefire MTK-3301 , which has been running well for over 6 years.
> Noticed today that ntp was reporting 1999 .

GPS has a 10 bit filed for the week number.  That works out to be about 20
years.
  https://en.wikipedia.org/wiki/GPS_Week_Number_Rollover
Or search for WNRO.

It rolled over recently.  But that doesn't mean your GPS unit will start
screwing up.  The firmware can compare the date from GPS with the build date
of the firmware.  That gives the firmware a lifetime of 20 years starting at
firmware build time.  Any dates before the build date get bumped up by 1024
weeks.  You may have to bump by multiple steps of 1024 weeks.  (Loop until GPS
time > build-time.)


Software like GPSD and NTPD can do the same thing.  That gives you a lifetime
of 20 years after the software build time.  If you can rebuild, the 20 year
window keeps moving.

If you are using ntpd, you can fudge the time.


--
These are my opinions.  I hate spam.