Hi David,
That sounds good, Folkert - perhaps you might publish the details
somewhere? I'd like to try it myself, but my Linux and C knowledge
is limited.
Here it is:
http://vanheusden.com/time/rpi_gpio_ntp/
Please let me know if anything is unclear: I'll then enhance e.g. the
readme.txt and such.
For comparison, on three RPi cards here with modified kernels to get
PPS from a GPIO pin, using ntpq -pn I see jitter values of 0.002,
0.002 and 0.002/0.004. The 0.002 seems to be near the sys_jitter
limit as reported from ntpq -c rv.
That's indeed better. The results I see are probably also influenced by
the fact that this RPI also does other things (software defined radio,
camera and measuring the light intensity outside).
Cards 1 and 2 are just doing NTP, the third card is running a data
collector processing signals from a DVB receiver stick, and sending
the derived data over a Wi-Fi link to a PC running Plane Plotter
using the dump1090 program. This gives a CPU load around 35%. It
would be interesting to know how your version handles a busy RPi.
Hmmm, I'll see if I can setup an RPI which only does the time keeping
and see if that gives better results.
Folkert van Heusden
===========================================
Thanks, Folkert, that's most helpful! One thing which is unclear to me is
what do you mean by pin 8? Is that a programming number, or does it refer
to the GPIO header? I did try and find this in the RPi documentation, but
it's not clear.
I'm currently using NTP driver type 22 on the RPi I would like to test with.
If I move to the type 28 driver it doesn't matter that PPS is left supported
in the Linux kernel. Please confirm there is no need to revert to a kernel
without PPS support. Is there a simple way of stopping the OS stealing that
GPIO pin - turning off PPS support with a simple edit?
What might matter, of course, is that I would need to move the actual PPS
signal to a different pin as kernel-PPS and your program would not live
together, as both would want to grab that pin. So it may mean making a
small hardware change as well if I can't turn off PPS support.
One thing you might want to try is to pulse one of the GPIO pins in response
to the rising-edge interrupt you get, to see what the delay is when measured
by a 'scope.
Many thanks for making this available.
Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
_______________________________________________
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.
