[ntp:questions] u-blox reference clock driver

[David Taylor]

This was posted by ***@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.

Here's the driver:
https://gitlab.cs.fau.de/luksen/ntp-ubx/blob/ubx/ntpd/refclock_ubx.c

The echo/timemark feature requires kernel patches on Linux (with gpio
pins) and FreeBSD (parallel port). It's probably easiest to test on a
Raspberry Pi with the Linux patch and via GPIO pins.

Linux patch: https://gitlab.cs.fau.de/snippets/28
FreeBSD patch: https://gitlab.cs.fau.de/snippets/29

I originally tried to send this message some time ago but it seems like
there were some problems with the mailing list. By now the thesis is
finished and you can find it here:

https://wwwcip.informatik.uni-erlangen.de/~in18otin/thesis.pdf

--Lukas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Terje Mathisen]

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

[David Taylor]

Post by Terje Mathisen

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

[Terje Mathisen]

Post by David Taylor

Post by Terje Mathisen

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