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

[Martin Boissonneault]

Hi!

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

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. 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. 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). Except for the PPS refclock, which has no timestamp attached (or maybe from the kernel?), the only source of GNSS information would be GPSd through SHM (PPS and serial timestamp) and the GPSd refclock (PPS timestamped).

  From what I observed, sometimes GPSd seems to associate the PPS to the wrong timestamp and that would  confuse NTPd. 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. One way to avoid this confusion would be to use UBX-TIM-TP and maybe UBX-NAV-TIMEUTC while using PPS.

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

  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.  My understanding is that UBX-TIM-TP is related to UTC, in iTOW format with leap seconds correction applied (See the image).

Now, in text:

Here, we can see the order and the timing:
21:20:36  L -> UBX TIM-TP,       336038.000 000000   Size  24,  'Time Pulse'
*** PPS ***
21:20:37  L -> UBX NAV-SOL,      336055.000 411205   Size  60,  'Navigation Solution'
21:20:37  L -> UBX NAV-TIMEGPS,  336055.000 411205   Size  24,  'GPS System Time'
21:20:37  L -> UBX NAV-TIMEUTC,  336055.000 411201   Size  28,  'Universal Time Coordinated'
21:20:37  L -> UBX TIM-TP,       336039.000 000000   Size  24,  'Time Pulse'
*** PPS ***
21:20:38  L -> UBX NAV-SOL,      336056.000 411412   Size  60,  'Navigation Solution'
21:20:38  L -> UBX NAV-TIMEGPS,  336056.000 411412   Size  24,  'GPS System Time'
21:20:38  L -> UBX NAV-TIMEUTC,  336056.000 411407   Size  28,  'Universal Time Coordinated'
21:20:38  L -> UBX TIM-TP,       336040.000 000000   Size  24,  'Time Pulse'
*** PPS ***
21:20:39  L -> UBX NAV-SOL,      336057.000 411617   Size  60,  'Navigation Solution'
21:20:39  L -> UBX NAV-TIMEGPS,  336057.000 411617   Size  24,  'GPS System Time'

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

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

  If so, I propose GPSd should decode and use TIM-TP to timestamp the PPS in SHM and it should be used with the NTPsec GPSd refclock. 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. It contains basic validity flags, but for a more detailed status, U-Blox recommends NAV-PVT be used.

Ref: https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_%28UBX-13003221%29_Public.pdf

That is my proposal,
Thanks,
Martin