Re: [gpsd-users] ntpd vs Venus638FLPx-L with week rollover bug

[David J Taylor]

From: Jeff Epler

Recently I decided to add PPS time synchronization to a Rasberry Pi,
and a Venus638FLPx-L on a SparkFun breakout board emerged from the
junkpile.  Sadly, I discovered that this device suffers from a bug and
doesn't report the correct time since the GPS rollover earlier this
year.

Its NMEA sentences report a date in November 1999, with two-digit
years: 101899. It appears that GPSD interprets the date as in the year
2099, giving a unix timestamp of around 4'096'000'000.  Of course,
this is too big for a 32-bit signed integer, so it ends up being
treated as -199'000'000 seconds somewhere along the line, and so gpsd
concludes the date is 19630912.

Is there (A) any knob I can turn in gpsd to work around this device's
bugs and make it useful?  Failing that, (B) is there anybody who would
like this board, if only for the curiosity factor?  It's one of these,
which I purchased in 2010:
https://www.sparkfun.com/products/retired/9133

In the meantime, I found a different module and got my NTP synced up to its 
PPS.
==========================

Jeff,

I'm concerned that I may encounter the same problem with some of my older 
modules.  I've heard that they keep working until they are powered down, and 
the problem appears on next boot.

One thing I had wondered about using reference NTP, and having other time 
sources available, would ne to simply comment out the NMEA part in the 
ntp.conf, but continue to use the PPS connection to the DCD line.  Possibly 
change the connector so that the data lines were disconnected, and just DCD 
and ground left.  I don't know how any of the NTP variants would respond to 
that.  My understanding is that the PPS would remain accurate, but I haven't 
checked that.

Of course, if you are relying on the date/time part from the device you are 
stuck.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: address@hidden
Twitter: @gm8arv