[GIS] gpspipe returns correct timestamp, but wrong date (21 dec 1995)

I'm having this strange issue where my gps pipe is returning the correct location and time but the wrong date (including year).

For reference, at the time of writing it is 06 aug 2015, 09:27 UTC).

I don't think it's a hardware issue, as on another device the GPS always returns the correct date/time. However, on one device most of the times it returns 21 Dec 1995, 09:20 UTC), so it gets the date wrong.

As you can see from the output below, it reports the year being 1995. The time is ok (09:20)

gpspipe -n 10 -r 

{"class":"VERSION","release":"3.4","rev":"3.4","proto_major":3,"proto_minor":6}
{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/gps0","activated":"1970-01-01T00:00:20.040Z","flags":1,"driver":"SiRF binary","native":1,"bps":4800,"parity":"N","stopbits":1,"cycle":1.00}]}
{"class":"WATCH","enable":true,"json":false,"nmea":true,"raw":0,"scaled":false,"timing":false}
$GPGSV,3,1,09,06,18,040,32,12,49,079,30,24,17,144,35,02,34,078,27*73
$GPGSV,3,2,09,14,32,240,29,29,51,202,24,31,34,306,18,25,82,339,00*7C
$GPGSV,3,3,09,125,28,205,30*78
$GPZDA,092014.00,21,12,1995,00,00*6C
$GPGGA,092014,5101.2493,N,00428.9160,E,1,07,0.80,15.88,M,47.128,M,,*76
$GPRMC,092014,A,5101.2493,N,00428.9160,E,0.0000,0.000,211295,,*26
$GPGSA,A,3,29,12,02,31,14,06,24,,,,,,1.9,0.8,1.6*38

A couple of reboots before this it returned this

gpspipe -n 10 -r 

{"class":"VERSION","release":"3.4","rev":"3.4","proto_major":3,"proto_minor":6}
{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/gps0","activated":"2015-08-06T09:18:29.903Z","flags":1,"driver":"SiRF binary","native":1,"bps":4800,"parity":"N","stopbits":1,"cycle":1.00}]}
{"class":"WATCH","enable":true,"json":false,"nmea":true,"raw":0,"scaled":false,"timing":false}
$GPZDA,091834.00,06,08,2015,00,00*69
$GPGGA,091834,5101.2482,N,00428.9175,E,1,07,1.20,20.04,M,47.128,M,,*72
$GPRMC,091834,A,5101.2482,N,00428.9175,E,0.0000,0.000,060815,,*2D
$GPGSA,A,3,25,29,12,02,14,06,24,,,,,,2.2,1.2,1.9*31
$GPGBS,091834,13.04,M,13.57,M,42.74,M*0A
$GPGSV,3,1,09,02,34,079,33,06,19,040,35,12,49,078,34,24,18,144,34*7A
$GPGSV,3,2,09,25,82,336,24,14,33,240,26,29,50,202,20,31,33,306,02*72

As you can see here the date is correct (06 Aug 2015).

On both machines the GPSD process is starting like this:

/usr/sbin/gpsd -bn -F /var/run/gpsd.sock -P /var/run/gpsd.pid /dev/gps0

What could cause the GPS to think it's 1995 ? The Latitude/Longitude is always correct, so it is able to communicate properly with the satellites.

Best Answer

This seems to be a known system/software bug:

http://forums.gpsreview.net/discussion/29425/garmin-gps-iii-plus-date-problem

http://continuouswave.com/ubb/Forum6/HTML/002815.html

http://www.colorado.edu/geography/gcraft/notes/gps/gpseow.htm

and from the gpsd manpage http://www.catb.org/gpsd/gpsd.html:

There are exactly two circumstances under which gpsd relies on the host-system clock:

In the GPS broadcast signal, GPS time is represented using a week number that rolls over after 2^10 or 2^13 weeks (about 19.6 years, or 157 years), depending on the spacecraft. Receivers are required to disambiguate this to the correct date, but may have difficulty due to not knowing time to within half this interval, or may have bugs. Users have reported incorrect dates which appear to be due to this issue. gpsd uses the startup time of the daemon detect and compensate for rollovers while it is running, but otherwise reports the date as it is reported by the receiver without attempting to correct it.

If you are using an NMEA-only GPS (that is, not using SiRF or Garmin or Zodiac binary mode), gpsd relies on the system clock to tell it the current century. If the system clock returns an invalid value near zero, and the GPS does not emit GPZDA at the start of its update cycle (which most consumer-grade NMEA GPSes do not) then the century part of the dates gpsd delivers may be wrong. Additionally, near the century turnover, a range of dates as wide in seconds as the accuracy of your system clock may be referred to the wrong century.