[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-users] Maybe beating a dead horse: Week number rollover

From: Adam Heller
Subject: [gpsd-users] Maybe beating a dead horse: Week number rollover
Date: Fri, 9 Nov 2018 09:09:09 -0500


I may be beating a dead horse here, but I wanted confirmation one way or the other.

I'm a developer at a company that uses GPSD in our embedded linux devices. GPSD is hooked up to a Trimble GPS that is known by Trimble to have the week number rollover issue. We're on gpsd 2.36 and only using the generic NMEA driver. (build config is down below this paragraph.)

When trying to confirm that we're affected, I'm using a Spectracom gps simulator and setting the sims date to April 6th, 23:50:00. After getting lock and waiting for the rollover to happen.... I'm not seeing anything odd. The date doesn't jump back the expected 19 years.

It could be a couple of things: me mis-understanding the problem, GPSD (even at 2.36) already being patched against it, or 1000 other things. 

I've attempted to search the git logs for the project and see when / if the issue was addressed within GPSD. It looks like the first commits were somewhere in 2010, which puts them after our release.

Any help or input would be appreciated. I'm obviously not an expert in gps/gpsd.


./configure --host=arm-linux host_alias=arm-linux --disable-python --disable-sirf --disable-tsip --disable-fv18 --disable-tripmate --disable-earthmate --disable-garmin --disable-evermore --disable-rtcm104 --disable-ntrip --disable-ashtech --disable-navcom --disable-ubx --disable-garmintxt --disable-itrax --disable-gpsclock
Adam Heller

reply via email to

[Prev in Thread] Current Thread [Next in Thread]