Print

[rfrazier]

I've been building an NTP server using a Raspberry PI and a Trimble Resolution-T GPS timing receiver.  Although I thought the power source I've been using was pretty good, I was getting funny spikes.  So, I did a bit of investigation on the web, and found the following review of USB chargers. 

http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab-apple-is.html

The charger that came top of the pops is for the HP Touchpad.  Since the RRP is £29 and they are available on Amazon for £5.99, I got two. 

Here's a graph showing the result of changing the power supply from what I had been using to the one for the Touchpad. (The readings are about every 16 seconds.)



So, I ordered a couple more.  Clean power is a good thing. 

Best wishes,
Bob

[Ralph Houston]

Do you really think 4 microvolts of drift is a problem? 0.25 V might be. You need to look at high frequency and mains frequency noise.

[rfrazier]

Thanks for the suggestion.  I haven't got around to a high frequency filter yet. 

However, I did add a thermal sensor (TMP102).  Using two sided thermally conductive tape, I attached it to the X2 crystal.  After empirically discovering the relationship between clock drift and temperature, I added a compensation factor to the timekeeping program.



Samples 0001-2000 are with the old power supply. 
Samples 2001-4000 are with the new power supply. 
Samples 4001-6000 also make use of the thermal sensor.

Best wishes,
Bob

[Ralph Houston]

This is an odd one! I'd say these microsecond shifts were interrupt jitter. Why interrogating a temperature sensor should affect matters I have no idea! Then again, you may have changed the load on the power supply...

[rfrazier]

It might be that the changing of the load is important.  The biggest, outlier, spikes I get are from changes in temperature due to changes in CPU load ( e.g., weekly cron jobs ).  Regularly interrogating the system to get the temperature keeps a small semi-constant load on the CPU, so there are fewer temperature spikes.  Combine this with the temperature compensation itself, and it might account for the decrease in overall fluctuation.  In any case, I suspect that it is going to be increasingly difficult (and increasingly more expensive) to reduce the fluctuations further.  So, I might settle for what I have.  

Best wishes,
Bob

[Confusticated]

changes in CPU load

Will cause changes in latency, have you investigated applying the Real Time Kernel patch set ?

[rfrazier]

changes in CPU load

Will cause changes in latency, have you investigated applying the Real Time Kernel patch set ?

I'm using the standard Raspberry source, 3.6.11, with PREEMPT set.  There aren't any clean patches available for PREEMPT_RT, as far as I can tell.  This kernel does all one to use chrt to set the priority of processes, which I've done. 

Best wishes,
Bob

[rfrazier]

I decided to add the Real Time patch after all.  It is a bit of a pain as it means that one as to remove the MMC (SD) module, which means boot off the SD but have the root file system on a USB stick.   In any case, one  gets threaded interrupts with the patch.  Giving the relevant ones a high priority made a bit of difference. 

Best wishes,
Bob