jbeale wrote:Thanks, got the source and I'll try a compile. By the way, after running the (Raspbian stock, non-PPS) ntpd process for a while, the ntp statistics log for frequency offset ranges between -37 to -38 ppm for my particular R-Pi. If I simply kill the ntpd process, does the Linux kernel still maintain that -37 ppm correction for the system time, or does it revert to an uncorrected clock?
Once the ntpd process is killed, your clock ticks normally without the guiding hand of ntpd. The process of slight, constant corrections to time by slewing the clock will stop.
jbeale wrote:Another question: with the 3.1.9-pps+ kernel and the pps_gpio module installed and the PPS signal connected, I am getting two lines added to the 'dmesg' log file every second, as below. How can I turn this off? I want to use dmesg to see other things like USB device connections, etc. and a lot of megabytes are accumulating in the /var/log directory.
edit: googling around, it looks like "PPS DEBUG" is an option compiled into the kernel, unfortunately.... Looks like I'll need to learn how to compile my own kernel!
Yep, sorry about that. I'm having problems getting it stable, so I've been using PPS debug. I can compile a version of the kernel without it for you if you'd like.
jbeale wrote:In case of interest I attach a graph of the drift of the R-Pi clock (with NTP turned off) relative to a more stable external PPS signal. You can see that the delay is variable but always positive (on time or late, but never early.) Superimposed on that is the longer-term drift.
A slight drift is okay though, that's what ntp is designed to mitigate, especially with the help of an external syncing source (PPS).
Are you saying that you've got PPS working successfully with the Pi?