[time-nuts] NTP to discipline Raspberry Pi

[James Peroulas]

>
> Date: Fri, 26 Jul 2013 12:27:50 +0200
> From: mike cook <mc235960 at gmail.com>
> To: Discussion of precise time and frequency measurement
>         <time-nuts at febo.com>
> Subject: Re: [time-nuts] NTP to discipline Raspberry Pi
> Message-ID: <D7F2DE71-32BC-4F54-8FFF-5E2027A57C23 at gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> Le 25 juil. 2013 ? 05:21, James Peroulas a ?crit :
>
> > I was hoping to measure the ppm error of a Raspberry Pi's crystal using
> an
> > NTP client running on the Pi itself. The NTP client reports a ppm
> > correction that I find to be consistently (measurements performed over
> > several days) off by about 10 ppm compared to what I measure using my GPS
> > calibrated frequency counter (HP5328). Specifically, the Pi reports a
> > required ppm correction of -33 ppm whereas I consistenngtly measure a
> > required correction of -43 ppm on my frequency counter.
>
>    Could you let us know what crystal you were measuring? From the  design
> docs there are 2 on the board  , one at 25 MHz and one  at 19,2MHz. The
> 19.2MHz is the one used to derive the ARM clocks.


Apparently, the 25MHz crystal is used only for the ethernet port, so I
didn't bother with it at all. To measure the 19.2MHz clock, I brought it
out to one of the GPIO pins, after dividing by 2. Assuming that the
internal divider was working properly, I _should_ have been measuring the
crystal's PPM error, but I didn't actually probe the crystal itself... I
just added the utility I used for this (gpioclk) to my WSPR fork, in case
you find it useful. You can place either the crystal or PLLD (after
dividing) on the gpioclk pin using the gpioclk program:
https://github.com/JamesP6000/WsprryPi

NTP reports the system clock frequency drift ( which I guess is the pll
> drift), and not the crystal frequency drift, so that may explain what you
> are seeing.


Well, the pll output error would be the same as the crystal error, assuming
that NTP was correctly informed of the nominal PLL frequency. What I think
might be happening is that the NTP reference clock might have a nominal
frequency of (something like) 1.000002MHz but NTP was incorrectly told
(through kernel headers) that the nominal frequency was 1.000000MHz. It
would then have to apply a -2PPM correction in addition to the actual PPM
error of the crystal in order to discipline the clock.

I'm embarrassed to admit it, but I hadn't updated the system on this RPi's
SD card. After a dist-upgrade, there is still a bias, but it's only 2.5 PPM
or so now, which isn't a problem for WSPR. I'm still going to try to track
it down. This does at least show that there is a software issue somewhere...

James

-- 
*Integrity is a binary state - either you have it or you don’t.* - John
Doerr