[time-nuts] NTP to discipline Raspberry Pi

[mike cook]

Thanks for that James.

Le 27 juil. 2013 à 04:26, James Peroulas a écrit :

>> 
>> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.