[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: Gary E. Miller
Subject: Re: [gpsd-users] Maybe beating a dead horse: Week number rollover
Date: Sat, 10 Nov 2018 11:26:22 -0800

Yo Adam!

On Sat, 10 Nov 2018 09:33:54 -0500
Adam Heller <address@hidden> wrote:

> As far as the build, it may be oddities with our arm-linux toolchain /
> linux distro etc.

If it is sorta standard then I'd like complete patches.  Usually if one
person reports a problem, there are many other silent sufferers.

> 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

Patches welcome.

> Ah, as far as gpsd having a hint to the current year from the clock...
> That's an interesting one.

Yes, a continuing source of irritation.  Our best recommendatatio so
far, on RTC failure, is to reset the system time to the last time
of some canary file.

But that does not completely solve the week roll-over issue.

> So I'm guessing I'll have to do the week number calculation manually?

Not completely.  The file timebase.c has functions for doing that.
There are also many tools available to do that job.  But it does
not solve the rollover problem.

> Hopefully time isn't going to be going backwards any time soon,

You never know.  Many GPS hard code the build date in their firmware,
and that, +19, becomes their rollover data.

> maybe
> I can hard code in the current build year.  I think that's similar to
> the solution / example code Trimble supplies.

gpsd could easily do that, but there is strong resistance to the
concept.  That would break an aweful lot of the gpsd regression tests,
which would be scary.

Maybe gpsd should add a CLI option to enable forcing a minimum
year.  That would not break the regression tests, and provide a knob
for people with GPS receivers that are problematic.

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

Attachment: pgpHIqpiRPWcP.pgp
Description: OpenPGP digital signature

reply via email to

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