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

[Martin Boissonneault]

Hi Gary!

  Your reply de-cluttered my brain just the right way. Thanks!

On 2019-04-03 19:54, Gary E. Miller wrote:
> > 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.

  Good to know.

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

  Agreed.

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

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

  To GPSd's defense, it was while I tried to compensate the serial 
timestamp's delay. One way to do this is to over-compensate the serial 
message delay. PPS gets wrong by one second! I was changing settings 
here and there, If I see it again, I'll try to capture some info.

   It is now irrelevant. Read on...
> >     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".

  True, the qErr value is too small to affect my timing. That value is 
useless in my context.

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

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

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

There is no point in decoding TIM-TP unless someone needs qErr. I don't, 
and I guess few do. As for the NTPsec GPSd refclock, it's not the best 
way to do it. There might be edge cases, but SHM is the best way.

> > That is my proposal,
I withdraw my proposal ;-)

> But I suggest you learn how things really work first, Get the separate 
> concepts separate in your mind. 

  I did, thanks to your reply!

  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.

  GPSd does all I need. I need ONLY ONE refclock for NTPsec to use, the 
SHM refclock that relates to PPS. That's it! No need to try to 
compensate serial timestamp lag, no SHM refclock for it needed too. No 
GPSd refclock needed either.

  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.

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

> RGDS
> GARY

Thanks again Gary,
Have a good day!

Martin Boissonneault
near Montreal, Quebec, Canada