Re: [ntp:questions] u-blox reference clock driver
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 -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] u-blox reference clock driver
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 -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] u-blox reference clock driver
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 -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
