[ntp:questions] u-blox reference clock driver
terje.mathisen at tmsw.no
Sun Aug 12 13:38:34 UTC 2018
David Taylor wrote:
> On 11/08/2018 12:29, Terje Mathisen wrote:
>> David Taylor wrote:
>>> This was posted by lukas at fridolin.com on the NTP hackers list, just
>>> in case you missed it.
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi,
>>> I've been writing a reference driver for u-blox GPS receivers as
>>> part of my master's thesis and thought ntp hackers might be
>>> interested in it. Additionally to normal PPS operation this driver
>>> can make use of the u-blox's "Timemark" functionality.
>>> It does this by enabling the PPSAPI echo, which generates an echo
>>> pulse right after receiving a PPS pulse. This echo is connected to
>>> EXTINT0 on the u-blox, where it is timestamped. So now I have the PPS
>>> timestamp as a local time and the timemark as the receiver time to
>>> calculate an offset. The cool thing about this is, that the offset
>>> does not include the local interrupt latency anymore, which leads to
>>> less jitter.
>> This is indeed cool, do you have any graphs/stats for the
>> actual/remaining jitter?
> There are some histograms in his thesis for various conditions of the
> Raspberry Pi which I saw on a quick glance. Take a look at Chapter 4,
> page 35. Graphs on p.40 onwards.
It is clear that having a way to directly measure and correct for
interrupt latency is good, also that modern multi-core cpus with
powersave and frequency scaling features leads to worse timekeeping.
The u-blox still looks like a nice alternative to the oncore for cheap
high-performance reference clocks.
Do you know if it also uses Glonass and Galileo sats? That would remove
one point of failure with the current system which is almost completely
GPS based for all the reference clocks in the NTP ensemble.
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions