[gpsd-users] possible week rollover problem

[Paul Fox]

i've been seeing bad dates from gpsd which seem to indicate a week
rollover issue.  i've been running gpsd 3.9, which i realize is out of
date, but which i think is more recent than most "week rollover"-related
commits i could see in the git log.  (i've now upgraded to gpsd 3.15,
so i'll see if the problem described below reappears.)

i have two BU-353 usb dongles:  one older (sirfstar 3?), the other a
newer S4 with a sirfstar 4.  (yes, i've read the FAQ, and it's slow
to acquire sometimes, but i needed something in a hurry at the
time.)  they both exhibit similar date issues with gpsd. 
unfortunately, it's hard (because of the binary protocol) for me to
trivially check them against something other than gpsd.

what i've observed:

1) a few weeks ago i took a weekend trip, and the timestamps recorded
    by my application for the entire trip were in 2035.  comparing
    closely on my return, the delta from the true time was
    approximately 19.6 years.  i didn't notice the problem until i
    examined the trip logs days later, and by that time, the problem
    was no longer occurring, so i have little other data to offer. 
    the laptop may or may not have been rebooted in between.  (fwiw,
    my logging software accesses gpsd in nmea mode.)

2) earlier today, using either of my receivers with gpspipe, and using
    either -r or -w, i got dates in october of 1918.  the exact delta
    from true date was very close to 6 19.6 year rollover intervals. 
    while this was happening, gpsmon was reporting a correct date
    (8/25/15) in its "Time:" field, but i don't know if that field
    represents system time or gps time.

    in an attempt to see whether it was my device or gpsd that was in
    error, i stopped gpsd and used gpsctl to switch the device to
    NMEA mode.  accessing the serial port directly showed that the
    device's GPRMC sentences were giving the correct 8/25/15 date.
    i restarted gpsd, and the 1918 dates were gone:  i now see correct
    dates everywhere.  so the test was inconclusive -- perhaps the
    device was fixed due to the mode switch, or gpsd was fixed due
    to the restart.

if this is a known issue with the sirf chipsets, then i'll probably
put a bandaid into my application and call it a day.  but i'm also
happy to do more debugging/logging, or add instrumentation, if that
would be helpful.

paul
=----------------------
 paul fox, address@hidden (arlington, ma, where it's 72.1 degrees)