✘0.250ppm/°C

Gary E. Miller gem at rellim.com
Sun Nov 6 19:27:49 UTC 2016


Yo Achim!

On Sun, 06 Nov 2016 14:22:10 +0100
Achim Gratz <Stromeko at nexgo.de> wrote:

> Gary E. Miller writes:
> > Ntpviz now has a plot for frequency vs temp.  The results are
> > interesting.  
> 
> …wasn't it you who said just two weeks ago that they wouldn't be?

Maybe I should have said illustrative?  It makes visually obvious Many
details people have been arguing over in the abstract.  I'm seeing at
least 4 different things going on in that graph.

> > Attached is from a Pi3.  It plots the Local Frequency Offset vs. the
> > Pi CPU temp.  
> 
> You really need to record the temperature aligned with the loopstat
> values if you want to correlate them.  I actually read it out for each
> PPS timestamp, then average onto the next loopstat value (I'm running
> the loop at poll=4, so 16 seconds).  The temperature measurement on
> the Pi is quite noisy, even though it appears they already do some
> sort of filtering on it.

Yeah, I'm starting to think we need to create a whole daemon devoted
to logging, instead of the little throw away scripts in contrib.

> > By eyeball looks like a frequency shift of 0.250 ppm/°C  
> 
> The denominator is a temperature difference, which can't be reported
> in °C; so that should be ppm/K.

One °C is one °K for ratio purposes.  The offset cancels out when youu
compute the delta.

> Over a period of time
> longer than a week you need to take crystal aging into account also.

I think my poor control of the test room temp vastly outweighs the
aging.  So I'm pondering some sort of chamber.

> I'm only using values where the loop has converged to better than 1µs
> for the fit.

But that's the thing.  As long as the RasPi has GPS lock, any aging or
temp error is correctetd in the loop.  Unless you want to provide good
time with long GPS outages the aging is not important to NTP operation.

> In order to reduce the disturbances by fast ambient temperature
> transients now that the heating season has begun, I've bubblewrapped
> my rasPi (still in it's case) + GPS module and put it into a
> corrugated cardboard box with some slits cut to feed the cables
> through.

Ditto here on one of my RasPi.  That clearly buffered the RasPi a bit
from room temp, but magnified the load factor effect.  So on balance not
a win.

> I'll have to see how to
> get some finer control over that load (and maybe use a second core
> for "heating") so that I can operate exactly on the zero-TC point.

I'm pondering a more direct thermal control.  Fans, heaters, etc.  But
to me that is very much a low priority.

My concerns are different than yours.  I could care less if the OSC
frequency drifts, as long as NTP applies a good loop correction.  What
I find worthy of fixing in the graphs is the frequency spikes, the
temp related and especially the temp unrelated.  What other forces are
changing the frequency.  Ts there some way to change the loop control to
improve time and frequency accuracy?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161106/fea862c0/attachment.bin>


More information about the devel mailing list