[Top][All Lists]

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

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

From: Mike Tubby
Subject: Re: [gpsd-users] Maybe beating a dead horse: Week number rollover
Date: Sat, 10 Nov 2018 15:28:11 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 11/10/2018 2:33 PM, Adam Heller wrote:

As far as the build, it may be oddities with our arm-linux toolchain / linux distro etc. I'm not at my work computer but there was a missing header for fd_set <sys/select.h> in one file, i had to explicitly pass -std=gnu99 to get around errors being thrown for the inline asm in one of the headers as well.  I can send you a patch on Monday if you're interested to see what I had to change to get this building. ... All that being said the only things I really needed to compile in were NMEA183 support, I'm wondering if my scons config was off....

Ah, as far as gpsd having a hint to the current year from the clock... That's an interesting one. Obviously we have a clock on the boards, however it's all pinned to a tiny watch cell RTC battery which likes to die if the units aren't hooked up to a power supply very often (they get trickle charged when the units powered). And these are all units that last saw production between 2010 and 2013. Even my 3 development units all had bad RTC batteries (and therefore system time showed as unix epoch on boot).

So I'm guessing I'll have to do the week number calculation manually? Hopefully time isn't going to be going backwards any time soon, maybe I can hard code in the current build year.  I think that's similar to the solution / example code Trimble supplies.


We have similar problems with our products (also ARM based, also with a battery backup that cannot wholly be relied upon).

Firstly, the air-interface documetn ICD-GPS-200 specifies GPS time in the form Week Number (0-1024), Seconds into Week (0-604799) and UTC Offset.

Most modern GPS receivers fix the 1024 week number roll-over internally.  For those that don't the problem arises every 1024 weeks (19.69 years).  The hack which I used in my code and the Trimble TSIP clock driver works once - for the first roll-over - a different solution is needed for subsequent roll-overs which includes some sort of state or memory.

Depending on how long your products need to last an alternative hack can be in the form:

    #define GPS_START_YEAR     1986

    unsigned short sw_build_year;
    unsigned short min_weeks;
    unsigned short week_no;

    sw_build_year = get_year_from_compile_date();    // fetch the year from your software compile time - you provide this

    min_weeks = (sw_build_year - GPS_START_YEAR) * 52;

    week_no = get_week_number_from_gps();        // get GPS week number - you provide this

    for (; week_no <= min_weeks; week_no += 1024);    // fix up week number - convert to extended week number

our newer software to run on old products does this and it fixes the problem for around 18-19 years on from when we release a drop of software.



On Sat, Nov 10, 2018, 01:45 Gary E. Miller <address@hidden> wrote:
Yo Adam!

On Fri, 9 Nov 2018 20:50:16 -0500
Adam Heller <address@hidden> wrote:

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

Ouch again.  Anything we could do to make that easier?

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

Yeah, we assume that...

The code to handle week rollover is in timebase.c.  It needs your system
clock to be close before starting gpsd.

We look forward to the results of your tests.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

reply via email to

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