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 <mc235...@gmail.com> >> To: Discussion of precise time and frequency measurement >> <time-nuts@febo.com> >> Subject: Re: [time-nuts] NTP to discipline Raspberry Pi >> Message-ID: <d7f2de71-32bc-4f54-8fff-5e2027a57...@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.