[Top][All Lists]

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

Re: [gpsd-users] Determining when the time has been corrected

From: Simon Haines
Subject: Re: [gpsd-users] Determining when the time has been corrected
Date: Thu, 18 Oct 2018 10:26:36 +1100

Thanks Gary, I disconnected gpsd, decoded the UBX protocol, and confirmed the number of leap seconds reported at boot is 15 (from the NAV-TIMEGPS message with the 'validTOW' flag set). This is later corrected to 18 when the 'validUTC' flag is set. So that explains that, thanks for helping clear that up. Why persist with the ancient NEO-6 devices? I'm upgrading the firmware of the embedded systems attached to hundreds of them in the field.

On Wed, 17 Oct 2018 at 15:35, Gary E. Miller <address@hidden> wrote:
Yo Simon!

On Wed, 17 Oct 2018 11:12:01 +1100
Simon Haines <address@hidden> wrote:

> The fix.time property is approximately UTC + 3s before a correction,
> and exactly UTC after a correction.

Yup.  Pretty common.  The ROM in your GPS was burned when the
GPS-UTC offset was 34 seconds.  Between 2009 and 2017.  Now
the GPS-UTC offset is 37 seconds.

When your GPS turns on, it uses the 34 second value.  Later, your
GPS hears from the GPS the current offest is 37, and your time jumps
by 3 seconds.

When you shutdown you GPS, it does not store the new offset.  So next
reboot the cycle starts over again.

> It's not a caching issue, when a
> correction comes, successive messages wind back the time.

Right, it is a FAILURE to cache the correct offset for the next

> can tell the uncompensated GPS time is not available through gpsd?

gpsd just reports what your GPS sends it.  gpsd has no way to know your
GPS is confused.

> I need to step around gpsd and read the raw messages to get GPS time?

No, you already have the GPS time.  and a bad offset.

> Because the corrections usually come within 7 minutes of boot,

Yup.  The ephemeris takes about 15 minutes to send.  So on average
you only have to wait 7 minutes until the part of the ephemeris
with the GPS-UTC offset is received from one of the sats.

> sometimes within 1 minute, I don't think the device is waiting for a
> full almanac download before issuing a correction as this can take 12
> or so minutes (I believe)?

Correct, it just needs to get to the part with the good stuff, not a
whole cycle.

> One possibility is that the device is
> applying an offset pre-programmed in its firmware until it can
> somehow determine the correct one, and a +3s figure would put the
> date of the firmware between 2009 and 2011.


> I guess I'll have to
> follow up with uBlox on this theory.

Or use the ubxtool to watch the ephemeris come in.  When you see that
message with the GPS-U}TC offset, then the time gets fixed.

You can buy a new u-blox 8 for $10, why fight it?

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]