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

[Adam Heller]

Mike,

Yeah, I managed to reproduce the rollover today. Not sure what I was doing wrong yesterday but today the date jumped back as expected.  Spent the other half of the day getting the latest gpsd release compiling for our platform.

Am I correct in assuming that gpsd handles the rollover in the newer relases?

Adam

On Fri, Nov 9, 2018, 11:35 Mike Tubby <address@hidden> wrote:

Adam,

I can't speak for GPSD per-se but we have a number of products based on older Trimble GPS receivers (SV6, ACE-II, ACE-III and Lassen-iQ) that are used both with our own applications and with NTP using Trimble TSIP binary.

The older GPS receivers reported the week number in the range 0-1024 and wrapped back to zero as per the air-interface description (NavStar ICD-GPS-200) in August 1999 and will presumably do the same thing again this time. These were fixed, last time, by doing:

    if (week_number < 990)
            week_number += 1024;

in various drivers.  This hack is also in the Trimple RefClock driver in NTP.

When we test the oldest receivers with a simulation we built using a HackRF we do see them jump back 19 years as expected.  The ACE-III documents support for 'Extended Week Number' and states that it is good to 2017, however have find it correct beyond the April 2019 WRNO. The Lassen-iQ is also documented as supporting extended week number but claims to be good to 2024.

I expect that Trimble have been addressing this issue by using a date/constant based on when the firmware was built or some other trick to ensure that week number only ever goes forward, thereby masking the problem.  YMMV.

Mike

On 11/9/2018 2:09 PM, Adam Heller wrote:

All,

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.

Adam

./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

https://www.heller.photo

--

Adam Heller

https://www.heller.photo