Re: [gpsd-dev] U-Blox M8, PPS and NTPsec - GPSd logic enhancement

[Gary E. Miller]

Yo Martin!

On Wed, 3 Apr 2019 18:28:00 -0400
Martin Boissonneault <address@hidden> wrote:

>    I'm using a U-Blox M8 GNSSr to provide timing to NTPsec through
> GPSd. In addition to pool and fixed servers, I use the PPS and SHM
> refclocks with the PPS timepulse and they are working OK. I have
> configured the GPSd and the SHM refclocks for time stamping and I am
> having issues with both. For that reason, I made them /noselect/.

Known issue, there is no way to get the serial timing from a GPS to
be anywhere close to the quality of PPS or network NTP time.

> Except for that issue, the setup works fine now. NTPd reports my
> offset to be about 60ns from UTC. Not bad for an inexpensive
> Raspberry Pi 3B+!

The granularity of the RasPi 3B+ clock is 52 ns,so abuot perfect.

> Context for the suggested improvement:
> 
>        I cannot use the serial timestamp without risking NTPd jumping
> to the wrong second. The serial timestamp currently is from UBX
>     NAV-SOL.

Depends.  On u-blox, it comes from the first time stamped message, what
ever that is.


> The M8 sends the messages with an offset that jumps
> ~100ms up and down about every 45 minutes. Since the offset is too
> large, NTPd won't use it.

Yup.  Much of this is due to variable processing time in the GPS to
arraive at a solution, and variable time to transmit the variable
length data over the serial port.

> I tried to compensate it in the refclock
>     settings, but doing so sometimes gets NTPd to jump one second
> (wrong time!) and sticks there until it figures it's mistake and flag
> the M8 timestamp as a falseticker (which is right at that time).

Yup.  Which is why you use noselect.

> Except for the PPS refclock, which has no timestamp attached (or
> maybe from the kernel?),

ppstest /dev/pps0

>Look at:  the only source of GNSS information would be
> GPSd through SHM (PPS and serial timestamp) and the GPSd refclock (PPS
>     timestamped).

Make that an or, not an and.  No need for both.

Also, we need to make clear distinctions between gpsd doing PPS and
the NTPsec gpsd refclock.  The former is well tested, the later not
well tested.  Discuss the former here.  Discuss the later over
at NTPsec.

>    From what I observed, sometimes GPSd seems to associate the PPS to 
> the wrong timestamp and that would  confuse NTPd.

Now that is unusual.  At least native gpsd.  As long as your RasPi has
other network chimers that should never happen.  It can happen when you
have a voltage mismatch on PPS line, or large CPU load.

> Since UBX NAV-SOL
> (or almost all other messages!) is related to the navigation epoch,
> the time within the messages is /LATE compared to PPS//.

Yes, always.  The PPS is always before the serial data.  The serial
data is the result of post processing the measurements at the PPS
instant.

> /One way to
> avoid this confusion would be to use UBX-TIM-TP and maybe
> UBX-NAV-TIMEUTC while using PPS.

Nah.  They all report the same time.

>   The message flow goes like this:
> NAV-xx(/previous, late/) + UBX-TIM-TP(/early/), PPS(exact), 
> NAV-xx(/late/) + UBX-TIM-TP(/next, early/)

Sometimes.

>    The UBX-TIM-TP announces the timestamp of the /NEXT/ PPS
> timepulse. It's an /advance/ message, so it's NOT affected by serial
> transmission buffering and other delays, except if if the serial line
> is overloaded by too many messages.

There is useful info in UBX-TIM-TP, but the time is not it. gpsd, has no
issue relating the PPS to the proper second, once monstly converged.

qErr is all that UBX-TIM-TP supplies that is unique.  And that is
usually too small to matter with your 60 ns "offset".

>  My understanding is that
> UBX-TIM-TP is related to UTC, in iTOW format with leap seconds
> correction applied (See the image
> <cid:part1.525F33EB.C84BCD75@ve2mrx.dyndns.info>).

Yes, most of the UBX messages have time computed that way.

Except it is not UTC, it is GPS time (weeks and TOW).  No leap seconds
in sight.

> Now, in text:
> 
> Here, we can see the order and the timing:

Nothing new there.  Don't get lost in looking at individual trees.

>    With UBX-NAV-TIMEUTC, we have the accurate UTC time of the last 
> navigation epoch (so, it's late related to PPS) but we still need to 
> correct for leap seconds?

No, just as it says, UBX-NAV-TIMEUTC is UTC.

But it does not matter GPS timme or UTC time (excapt at rollover).
The conversion is trivial.

>. That would mean that the time returned by 
> nearly all messages would be wrong (currently in the future) by (leap 
> seconds, currently 18) compared to UTC time?

Now you are really off in the weeds.

>    So, the UTC_time_at_PPS_edge = (last TIM-TP) or (next NAV-TIMExx - 
> (leap seconds))? Did I understand correctly?

A number of time scales here.  TIM-TP is GPS time, easiy converted to UTC.
UBX-NAV-TIMExxx are all slightly different UTC.  Let us not go there...

>    If so, I propose GPSd should decode and use TIM-TP to timestamp

No point.  gpsd knows the current time, and the PPS just marks
the start of the next second.  Been working fine for well over a
decade.  at least in native gpsd.  The NTPsec gpsd driver has been
orphan for years.

The only potential value in UBX-TIM-TP is qErr.

> the PPS in SHM and it should be used with the NTPsec GPSd refclock.

Except NTPsec gpsd refclock knows nothing of ubx, or any sentence
types at all.

> Only the LAST TIM-TP is valid if there are many in the buffer, and
> since it's sent early in regard to PPS, any transmission and buffer
> lag has no impact.

Except when it is too late.

> It contains basic validity flags, but for a more
> detailed status, U-Blox recommends NAV-PVT be used.

Which is why gpsd uses all available info to arrive at a status decision.

> That is my proposal,

Feel free to patch your code any way you want to.  But I suggest you
learn how things really work first,  Get the separate concepts separate
in your mind.

If you can improve your results, then post your results here.  Preferably
with ntpviz supporting data.

Just know that getting past 60 ns offset, when your clock resolution
is 52 ns, is pretty hard.  Usually done with layers of temperature
control.

RGDS
GARY
---------------------------------------------------------------------------
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

pgppNs2r2OjON.pgp
Description: OpenPGP digital signature