Question: GPS disciplined stratum 1 NTP service with PPS?

Dan Cross crossd at gmail.com
Sun May 12 19:36:25 PDT 2024


On Sun, May 12, 2024 at 10:14 PM Matthew Dillon <dillon at backplane.com> wrote:
> I don't think anyone has for DFly, but perhaps someone has done a GPS interface on FreeBSD.   parallel/pps is probably your best bet but the time-sync signal can be tricky without an input-capture timer.  You might be able to use BRK handling in the serial driver to detect the time-sync.  Polling won't work very well in terms of accuracy.

Thanks for the response, Matt. I actually got it working yesterday
after making a quick kernel mod to support the `PPS_CANWAIT`
capability for `time_pps_wait` and have been monitoring it; accuracy
is pretty good, usually +/- 10usec, surprisingly often sub-1usec. My
kernel patch is at https://bugs.dragonflybsd.org/issues/3368

I was going to write tomorrow or the day after, to give it a bit more
time to burn in.

> Also look into RS485 to RS232 converters, possibly.  You can the route GPIO to the RS485 side and if you need to invert it you can do that by selecting which of the two RS485 polarity data pins to shove the signal into.  You would need to bias the other polarity pin to roughly 1/2 the voltage to make it work reliably.

No need! I simply fed the DCD line from the GPS PPS output, and `gpsd`
is smart enough to deal with the polarity inversion (DCD is
active-low).

> A lot of people push those GPS receivers into raspberry PI's, Raspberry Pi Pico's, or Arduino Nano boards as an intermediary.  Depends how interested you are in learning basic micro-controller interfacing but these days it is fairly easy to get started... you can just do it in C and learn the hardware (which is usually fairly straight-forward).

I already do this professionally, but thanks for the tips! :-)

> Other popular microcontroller chips are the PIC series of chips, typically the PIC16 series (the PIC8 series doesn't have enough program space for anything serious).   All of those I think have PIO edge capture interrupts and some (like the PIC16) can even do automatic timer-capture-on-edge for fairly precise event timestamps.

What might be interesting is exploiting the IEEE 1588 in some NICs to
avoid the overhead of interrupt handling machinery entirely. That's
overkill for my application, though, and the RTL8111E's on the APU 1d
I have don't seem to expose hardware timestamps, let alone expose a
pin that I could wire to a PPS signal. But setting up a PTP
grandmaster on inexpensive hardware would be cool. Perhaps another
time.

        - Dan C.


More information about the Users mailing list