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

[Gary E. Miller]

Yo Martin!

On Thu, 4 Apr 2019 14:56:08 -0400
Martin Boissonneault <address@hidden> wrote:

> >>     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.  
> 
>    It happened when restarting NTPd+GPSd. Because of Stratum, the
> GNSS time ref gets picked before the other servers/pools are ready.

Not because of the stratum, because it is near the top, instead of
near the bottom, in your ntp.conf.  Also mark that time "noselect".

> Once they are ready, NTPd does detect and fix it. The time jump is
> the annoyance, it makes ntpviz graphs spike ;-)

Than don't do that...
 
> >> . 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.  
>    I am confused by the difference in the timestamp between TIM-TP
> and the other messages. However, I now understand TIM-TP is useless
> to me. So are the time differences in my context.

Easy to be confused about what time is where.  

The u-blox can be one, or all, of:

        GPS time         (GPS weeks, time of week)
        GLONASS time
        Galileo time
        UTC(USNO)
        UTC(GLONASS)
        UTC(BeiDou)

Best just to leave the defaults and use UTC(USNO) and GPS time.

>    My confusion was that I wanted to provide time to NTPd for use
> with the PPS refclock in the case it would be offline. That would
> require using the SHM relating to the serial messages or the GPSd
> refclock. But then, I would need to compensate for some of the delay,
> yet the square wave timing changes makes that somewhat pointless.
> Then came the idea of TIM-TP.

I suggest you look at how gpsd reports time in SHM again.  SHM(0)
is serial time, and SHM(1) is PPS time.  It all works fine.

>    GPSd does all I need. I need ONLY ONE refclock for NTPsec to use,

Well, not really.  You should have at least 3, so problem sources, like
your off one-seceond, are easily detected.

>    GPSd already timestamps the PPS SHM correctly. That's all I need.
> It will be right as long as the serial messages are not overflowing.
> Only 3 or 4 UBX messages are needed, 115200 bps will work.

9600 is usually enough.

>    Also, I think I should stop using the PPS refclock with the PPS
> SHM one. It might confuse NTPd. What do you think?

Some find it useful to compare the different ways to read the GPS
time.  Just in case one goes wacky.  But all you need is SHM() and
some network chimers to catch bad days.


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

pgpJHkkVRYrdU.pgp
Description: OpenPGP digital signature