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":"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}]}

A couple of reboots before this it returned this

gpspipe -n 10 -r 

{"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}]}

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.


This seems to be a known system/software bug:




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.

| improve this answer | |

I just went through solving this problem.
The post by AndreJ is accurate and helped to start my investigation as to why the system clock was so far off.
In my case, I'm connecting a GPS receiver to a Raspberry Pi 2 running Ubuntu 14.04. Raspberry Pis don't have hardware clocks and so early in the boot process, before ntp can set the clock, the time/date are set close to the beginning of epoch (Jan 1 1970).

This confuses gpsd: "Jan 1 00:00:13 ubuntu gpsd[814]: gpsd:ERROR: system time looks bogus, dates may not be reliable."

The solution for me is to run 'fake-hwclock' which stores the accurate date/time in a file and then sets the system clock from that file very early in the boot process. Even if your machine lacks a hardware clock with battery and has been powered down for awhile, this date/time setting will be accurate enough for gpsd to be able to "disambiguate to the correct date."

| improve this answer | |
  • That's also how we solved it. Nice to see it worked out for you as well. – ddewaele Aug 8 '15 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.