At the moment, I am recompiling the Wheezy kernel to add PPS support (required for NTP timekeeping amongst other things). However, I do also note the capability to add modules at boot-up by editing the file:
Are you sure you need PPS support? What type of device are you trying to link to ntpd?
The NTP server, ntpd, runs quite satisfactorily on the standard Raspbian kernel using the standard internet time services as its master time source. That was one of the first things I configured and had running on mine.
Have you considered using GPS receivers with NMEA output?
This one, for instance:
formatting link
Is powered through its USB connector and uses gpsd to interface it to ntpd. gpsd is a standard Debian package for connecting GPS receivers that use the NMEA protocol to ntpd.
Garmin also sell similar receivers but they generally need a 12v power supply and use serial connections, so you'd need a 12v PSU and a serial to USB adapter to connect them to an RPI. That said, suitable models are the Garmin GPS18 GPS19 (current models), GPS25 or GPS35 (look on eBay).
More detail on using gpsd is here:
formatting link
If the above doesn't help, you may want to ask on comp.protocols.time.ntp, which is apparently a good place to ask NTP-related questions.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
GPS with NMEA is worthless for accurate time sync. A network time source will normally perform much better. (unless your network is via WiFi or UMTS/GSM of course)
GPS can be used as a good timesource but you need the PPS signal. It can be fed to the kernel without PPS support, e.g. with gpsd.
However those that want PPS support usually know what they are talking about and want it for some reason.
I think the PPS support changes more than just the addition of some functions, that is why it is not a module. The reason I originally added PPS support to gpsd (which works reasonably well on a lightly loaded system) was that I did not like to recompile the kernel either. It takes a long time and makes tracking security updates from the distributor a lot more difficult.
Thanks for your reply, Martin. Yes, PPS is essential for precise timekeeping. I am linking devices which have a PPS output such as:
Adafruit GPS:
formatting link
and U-blox 7Q:
formatting link
NMEA alone is totally inadequate for precise time-keeping, as the serial output has a low prority within the GPS receiver and can, consequently, have a very large jitter. It may actually be worse than a reasonable Internet connection.
I am moderately familiar with NTP. Do you have an answer to my question?
Thanks for your comments, Rob. I have tried a user-mode program on the RPi which injects PPS times (from a specified GPIO pin) into the shared memory segment provided by (I believe) gpsd. With this program I can get down to around 5 microseconds averaged jitter on the RPi.
formatting link
Using kernel-mode PPS (and ensuring that the kernel is not compiled with "tickless" set) reduces the averaged jitter to 1-2 microseconds.
It is a pity that the default Raspberry Pi software is not supplied with PPS support from a programmable GPIO pin, and without "tickless".
Ok I'll admit that I forgot we are on a Raspberri Pi, not NTP, group. What gpsd can do is to receive GPS data on a serial port, and at the same time receive PPS pulses on a handshake line of that port, usually DCD.
However, while the Raspberri Pi does have a serial port, it does not come with a handshake line. So this function of gpsd cannot be used. Of course it is possible to have another program running that inputs a generic input pin and does the same thing as gpsd does.
The shared memory segment is not used by gpsd, it is used by ntpd. It is filled by gpsd or the special program you use.
.. and gpsd works very well indeed - thanks very much for that! The great thing about the user-mode program is that the pin to use can be specified on its command-line, whereas the kernel patch is to a port defined at patch time.
Well, I wrote the initial code for timesync in gpsd, but after me a lot of other people have further refined it. The command-line spec of the input pin is one of those changes made by others. In fact, when I wrote my code I was asked not to use any configuration options, in those days gpsd was supposed to be completely auto-configuring.
(the code auto-detects the presence and polarity of the PPS pulse)
I'm trying something similar, but NTP has a broken way of specifying source s. My GPS has a very jittery serial data, but precise PPS - but NTP refuse s to accept PPS when it departs from the GPS time, but the GPS time will be constantly moving.
But for the kernel, I have a project on github,
formatting link
rnomatic that builds kernels, and gpio_pps that allows a module to be loade d to specify the GPIO pin (since I'm swapping hardware the available pins c hange).
Is there anyway to just use /dev/pps0 and ppsctl that bypasses NTP complete ly and have the kernel itself sync to PPS? (Or I might write my own to use adjtime). I already have a GPS NMEA decoder that sets the time (actually a bit before due to serial latency) - that is webgpsd on github.
I must confess to not having seen this problem myself, but I always use other NTP servers to set the coarse time. You can mark the GPS serial server as "noselect", and just monitor it, if you like.
Are you allowed to connect to other NTP servers in the system you are building? That might solve the problem.
NTP will need to have a way of knowing the coarse seconds - it can't work from PPS alone. I'm wondering whether you may be in the situation of the man with two clocks, not knowing which is right, but if the PPS is working properly I would have expected NTP to choose it over the GPSD every time. There may be parameters you can twiddle, but perhaps the best approach is to ask the gurus over on:
nntp://comp.protocols.time.ntp
I have a feeling there's something obvious which I'm missing!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.