I've done that with a gps from adafruit, won't be much different I guess. Maybe a voltage level shifter?k.elliott wrote:My first project for the Rpi will be to implement a stratum 1 NTP server for the house using a low cost gps from spark fun.
My question is, can the gpio pins be used for the pps signal?
It may be a matter of recompiling the ntp source to look at a different pin, which doesnt really scare me.
all I can say is gimme gimme gimme some pi.
jbeale wrote:Only slightly off-topic: if anyone is interested in a very inexpensive GPS (or GPS + Glonass, or GPS + Baidou) receiver with 1-pps that has 10 nsec timing resolution, there is a "Kickstarter"-type project on (at Indiegogo) called NavSpark. At $19 it will be the least expensive timing-type GPS module I'm aware of. In addition, the baseband processing runs on a 32-bit CPU which at the same time as running the GPS, can host your own programs(!) written on via Arduino-style interface. The design is coming out of SkyTraq in Taiwan, which has already made some other, more expensive GPS units.
The project is still in funding phase and hasn't shipped yet so I don't have one, but I think this could be a good choice for a R-Pi GPS-based NTP server. It comes with an external antenna, using the tiny UFL connector. For most permanent installations you'll probably want a cable adaptor and use a longer cable run of something like RG-6 up to a rooftop location.
http://www.indiegogo.com/projects/navsp ... /x/6094574
I've got things working by making Chrony use its own PPS driver to query /dev/pps0. I was just wondering why I was having trouble getting gpsd to provide PPS data via the SHM driver. Here's my config:David Taylor wrote:Completely agree with you about the default OS for the Pi having PPS support, and the NTP as well! They should also not compile with the "tickless" option as that reduces the quality of timekeeping (as judged by NTP jitter). I've got all this working, so perhaps my Web page may help?
Code: Select all
refclock PPS /dev/pps0 lock GPS prefer refid PPS refclock SHM 0 offset 0.5 delay 0.1 refid GPS noselect leapsectz right/UTC
Code: Select all
localhost ~ # chronyc sources ; echo ; chronyc sourcestats ; echo ; chronyc tracking 210 Number of sources = 2 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PPS 0 4 377 17 -970ns[-1529ns] +/- 601ns #? GPS 0 4 377 19 -12ms[ -12ms] +/- 56ms 210 Number of sources = 2 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== PPS 22 11 339 -0.000 0.007 -5ns 899ns GPS 6 3 80 -436.984 1036.484 -33ms 8266us Reference ID : 184.108.40.206 (PPS) Stratum : 1 Ref time (UTC) : Tue Jan 28 19:12:41 2014 System time : 0.000000026 seconds slow of NTP time Last offset : -0.000000572 seconds RMS offset : 0.000000785 seconds Frequency : 39.256 ppm fast Residual freq : -0.000 ppm Skew : 0.008 ppm Root delay : 0.000000 seconds Root dispersion : 0.000018 seconds Update interval : 16.0 seconds Leap status : Normal
Yes, I did that. ppstest was successful, and Chrony is successfully using it directly, as I explained earlier. I'm quite confident that the problem is not the PPS hardware or drivers. I'm trying to work out just exactly what the problem is, however. All I have to go on is confirmation that gpsd was compiled to use the Linux kernel PPS API and the mystery creation of a /dev/pps1 that doesn't appear to correspond to any hardware attached to the Pi.David Taylor wrote:Make sure the PPS is working using sudo ppstest, then configure gpsd accordingly with sudo dpkg-reconfigure gpsd