|
From: | Martin Boissonneault |
Subject: | [gpsd-dev] U-Blox M8, PPS and NTPsec - GPSd logic enhancement |
Date: | Wed, 3 Apr 2019 18:28:00 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
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:
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: 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: 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. That is my proposal, |
[Prev in Thread] | Current Thread | [Next in Thread] |