David Taylor wrote:
On 11/08/2018 12:29, Terje Mathisen wrote:
David Taylor wrote:
This was posted by lu...@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?
Terje
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.
https://wwwcip.informatik.uni-erlangen.de/~in18otin/thesis.pdf
Thanks!
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
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
