-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Pulse Per Second (PPS) Support #882
Comments
We indeed do not support this yet, primarily because we didn't have people who wanted it and so couldn't ask questions, so thank you for asking :). I'll add this to the discussion internally for prioritization, but already have a few more specific questions:
|
I'm using an Ocilloquartz (now ADVA) product. I was using a Symmetricom product before. I've got another system where I'm using a u-blox GPS evaluation board. They all output a PPS which is connected into the computer on a serial port control line (DCD, I think). The steps to configure on Debian (and with NTPsec) are:
You can test the PPS input with
Another good way of testing this would be to get a Raspberry Pi (which are finally relatively available again) and a GPS HAT for it. Follow some HOWTO that uses gpsd and NTP or NTPsec, like this, which is the scenario "A" in the issue description: I recommend that because you'll probably eventually want to support that too, and because following a HOWTO exactly as written is the best first step. Once you have that working, convert it to the simpler scenario "B" (where you are just using PPS, no gpsd/SHM), still with NTP or NTPsec, using the notes above in this comment. Once you have that working, stop NTP/NTPsec and work on implementing support in ntpd-rs for using the kernel PPS API to get the pulses. As with anything, start by just logging them or whatever. Once you can get pulses into ntpd-rs, then wire them in as a clock source to discipline the clock. At that point, you have a working scenario B. Then you might consider implementing scenario A, talking to gpsd via SHM interface. If you go down the SHM road, see the recent changes relating to 32-bit time_t rollover: https://lists.ntpsec.org/pipermail/devel/2023-January/010167.html Alternatively, you might want to implement the chrony socket interface. I don't know anything about it, but it's apparently a thing that exists and is probably better than the SHM interface. Since you're new, you might just skip SHM entirely. I hope this helps. I'm available for more questions, though my response times may be longer than normal for the next month or two. |
Thank you for the information, this will definitely help when we get started on it. Timeline wise, we hope to have capacity to start working on this sometime this fall, but we don't have anything concrete yet. |
@davidv1992 if it can help, I may be able to lend you root access to a PPS-"enabled" Raspberry Pi. It's rather easy to cross-compile to the armv7l arch and it may allow you to test code easily. Ping me if needed 👍 |
We have such a raspberry pi ourselves so we should be good on that front, but thank you for the offer. |
I could be missing it, but at a quick glance, I'm not seeing any support for PPS input. Ideally, there should be support for two configurations:
A) Using SHM from gpsd. You might call this "SHM support" and consider it a separate feature request.
B) Taking PPS from the kernel PPS API and using it to discipline the clock. The seconds would be numbered from other (e.g. Internet) sources.
I use configuration B in production with NTPsec (and formerly with classic ntpd). I have telecom grade GPS clocks which provide a PPS output (among other things).
While such devices can often act as NTP servers, sometimes this is a separately licensed (expensive) feature. In any case, their NTP server implementations are generally not as good in some respects (e.g. not supporting NTS). Likewise, newer ones tend to support PTP, but again, that can be an expensive licensed feature.
So I just use PPS from them. This is probably more accurate anyway, and allows me to be stratum 1 instead of stratum 2. I'm not trying to operate standalone (i.e. with no Internet access), so I don't need to get the TOD from GPS via serial. (And on my previous clocks, it was wrong due to GPS rollover anyway.)
The text was updated successfully, but these errors were encountered: