[time-nuts] Designing an embedded precision GPS time

Attila Kinali attila at kinali.ch
Tue Oct 31 20:03:07 UTC 2017


Hoi Leo,

On Sat, 28 Oct 2017 11:14:08 +0100
Leo Bodnar <leo at leobodnar.com> wrote:

> > From: Attila Kinali <attila at kinali.ch>
> > Can you tell a little bit how your device looks like on the inside?
> 
> GPS is a Ublox.  MCU is Cortex-M7 and does not run any OS - just main loop with prioritised interrupts.  Network stack is hand-made. 
> I don't use saw-tooth correction in this device because +-11ns is not worth correcting for NTP application for such a budget device.
> If you can build a test NTP client system that can detect sawtooth 10ns offset from the NTP server I'd like to know how you did it.

True. An NTP server does not need to measure time better than 100ns or so.
10ns is probably more than good enough. But then, this raises the question
what your performance metric is that you optimize for?

If it is hold-over, then this will be limited by the TCXO and how well
you can measure its frequency, which in turn depends on how well you
can measure the PPS pulse. You say that your device is typically within
4-5ms in 24h of hold-over. That translates to frequency uncertainty
of approximately 5e-8. That's not that good.
To put this into perspective have a look at the two attached plots.
These are the PPM values that ntp reports for a standard server (HP DL380G7).
The first plot shows the long term variation of all the data I currently have.
The three jumps coincide with days when we restarted ntpd. As you can see,
the long term variation of the crystal frequency is well below 0.5ppm. The
second plot zooms in into one of the day with large variations. The worst
of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens
instantaneous, then this would result in a hold over performance of ~0.9ms
in 24h. Yes, this is not a fair comparison. The sever is in a room where
temperature is pretty much constant (sorry, I don't have any data on that,
but assume less than 5°C  variation within a day). And it's not true hold
over performance, but a guestimation from the ntp provided loop data. But
even if we add a factor of 10, this simple, unstabilized, unsophisticated
PC comes pretty close to the performance your device claims. And that's not
even a PC with a good crystal (I have measurements of others, that showed
variation of less  than 2ppb over months in rooms without air conditioning).

Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver,
put everything in a metal box and just use normal ntpd, i'd expect to
have a hold over performance of better than 100ms/24h (assuming 1ppm
stability of the crystal), probably in the order of 10ms/24h and it would
have no problems handling a humongous number of clients, thanks to the
fast CPU (1.4GHz) and the Gbit/s ethernet interface.

So, why does a simple PC with ntp do such a good job? The secret
lies in the measurement: Very much simplified, ntp measures the
frequency in 1000s intervals. Measurement uncertainty is reported to be
better than 100us per reference server. Ie the uncertainty is in
better than 1e-7 (compare with the estimated 5e-8 from above).
Add to that averaging over multiple reference severs (4 in this case)
and a sophisticated clock parameter estimation and the uncertainty
goes down quite a bit.

To summarize: If you want to improve your ntp devices hold over performance
you have to improve the frequency measurement and use a better clock modeling.
Ie, use a timing GPS receiver and its sawtooth correction, and model the
clocks frequency change over time.


			Attila Kinali
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
                 -- Miss Matheson, The Diamond Age, Neil Stephenson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hakuoro.png
Type: image/png
Size: 52975 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20171031/dd5c6ec2/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hakuoro-zoom.png
Type: image/png
Size: 36082 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20171031/dd5c6ec2/attachment-0001.png>


More information about the Time-nuts_lists.febo.com mailing list