On 15/06/2020 19:00, David Woolley wrote:
[]
What is the clock resolution? If you try and measure jitters that
aren't several times the resolution, they are not going to be
particularly valid.
If the hardware clock is almost dead on, and the peak to peak dither is
just less than the resolution, there will be long periods in which it
will read as as zero, even though it is actually close to one resolution
unit. You could also get cases where dither was very low but read as
one resolution unit for long periods. In fact, if it was possible to
find tune the actual clock oscillator, during an ideal lock you would
have peak to peak dither, as measured, of one or two resolution units,
even though the actual phase noise was much less.
(Arguably, a jitter that is less than the clock resolution will result
in worse time accuracy than one that a few times it, as the clock
resolution will not be dithered out.
That makes the, normally unrealistic, assumption that the systematic
error is less than the clock resolution.)
The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock
resolution is in the nanosecond range. There is mention of 250 MHz as
well, which would be 4 nanoseconds. It would be nice to see numbers
which distinguish a little better than earlier RPi is "3" and more
recent ones are "1"!
I would also like to see whether the characteristics of the GPS and its
location make a measurable difference to the RPi's timekeeping. For
example: is it better to have a GPS with 3 service capability at a
location where the signal is poor, or is it masked by the RPi's
performance? All this with kernel-mode PPS.
--
Cheers,
David
Web: http://www.satsignal.eu
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
