I thought it would be fun to add a GPS+PPS source to my pfSense firewall to serve time to clients. I tested three different Garmin GPS receivers connected via DE9 or RJ45 RS232 communication and the NTP package in http://pfsense.org
GPS 16X LVS
GPS 18X LVC
GPS 19X HVS
I am sure others with more experience will find faults with my NTP solution, but it seems to achieve less than 10-15 usec offset/jitter. Might not be good enough for a financial institution or high speed data acquisition, but good enough for homelab use.
uBlox based GPS modules from 7th to 9th gen, can be purchased for half that price, or even less, if a naked chip on a tiny board and possibly some soldering isn’t a problem. Pratically all support PPS, even if there is no dedicated PPS pad/pin on the board.
Hmm, I guess it lies in the eyes of the beholder as to whether to consider any option a Rube Goldberg one. E.g., due to the much better performance of the u-blox units, there may be no need for an outdoor rating. Depending on circumstances, it may be possible to operate such a unit indoors and get reception good enough for timing (less so for positioning), as discussed in another recent thread.
Or, if that doesn’t work in particular circumstances, the receiver may reside indoors, and it’s only a COTS puck antenna with attached coaxial cable run that gets placed outdoors.
Either way, slightly different handiwork needed than what you did for your solution, but to me, it seems pretty much on par with what you did for your solution as far as Rube Goldberg worthiness is concerned. But the performance would arguably be better with a recent u-blox unit than with the slightly older Garmin units.
A bit pricier, but if reducing handiwork is a must, some vendors such as NaviSys and Navilock also offer outdoor rated units with PPS and serial (non-USB) interface based on u-blox chips, e.g., the NaviSys GR-801R.
I use a couple of these receivers, but they are tricky to setup.
And they need DB9 as well as USB (for 5V power).
There are various good sites on how to work with these.
It all depends on your situation, because if the roof of your building isn’t steel-enforced-concrete often indoor simple U-blox will work fine.
You can install a app on your mobile-phone and see how well it received and how many sat’s. That will give an idea what you need for good timekeeping.
Mine are under a wooden roof and do not need to be outdoors.
Sorry to say, but the PPS line doesn’t contrain time and date info.
It only pulses and is normally locked to the normal NMEA driver to combine the two for correct time and date.
That is the reason there are always 2 lines in there.
If you don’t do that and the internet drops, it won’t know what to do with those pulses.
I am by no means a NTPD algorithm expert, but I noticed if a source is marked as a valid PPS Peer o, NTPD uses that to sync and serve time to clients regardless if there a separate Active Peer * used for time data. If a GPS is being used for both a PPS Peer o and source of time data, it will be marked as PPS Peer o and there will be no other Active Peers * marked. The NTP Widget seems to display the Active Peer * even when the PPS Peer o is actually being used to sync and serve time to clients. Which source is actually served to clients can be confirmed with “ntpq -c sysinfo”.
As a test, I removed the NIST pool and added a single NIST server and marked it as no select. Seems to be using GPS for both time and PPS.
[2.7.2-RELEASE][root@pfSense.[redacted].com]/root: ntptime
ntp_gettime() returns code 0 (OK)
time e98edb42.843b1d0c Sun, Mar 3 2024 6:19:30.516, (.516527909),
maximum error 3633 us, estimated error 34 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -861.970 us, frequency -33.804 ppm, interval 256 s,
maximum error 3633 us, estimated error 34 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 4, precision 0.001 us, tolerance 496 ppm,
pps frequency -33.804 ppm, stability 0.024 ppm, jitter 8.414 us,
intervals 7152, jitter exceeded 877, stability exceeded 0, errors 1.
[2.7.2-RELEASE][root@pfSense.[redacted].com]/root: ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
o127.127.20.0 .GPS. 0 l 14 16 377 0.000 +0.391 0.565
132.163.96.4 .NIST. 1 u 13 64 3 53.417 +0.811 0.334
[2.7.2-RELEASE][root@pfSense.[redacted].com]/root: ntpq -c sysinfo
associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
system peer: GPS_NMEA(0)
system peer mode: client
leap indicator: 00
stratum: 1
log2 precision: -21
root delay: 0.000
root dispersion: 1.261
reference ID: GPS
reference time: e98edb4d.97dd5492 Sun, Mar 3 2024 6:19:41.593
system jitter: 0.392407
clock jitter: 0.007
clock wander: 0.000
broadcast delay: -50.000
symm. auth. delay: 0.000
[2.7.2-RELEASE][root@pfSense.[redacted].com]/root:
My understanding would be that the NMEA driver (20) is used to get both the second numbering from the NMEA data stream as well as the PPS pulses from the same driver, as also discussed in another recent thread. Note the server address, the RefID, and the lack of a star in front of any of the other servers on the billboard.
Thanks for sharing your solution! Small item, but quite interesting to see that BSD natively supports both DCD and CTS lines to serve as PPS input for kernel PPS. Linux typically only uses DCD, like illustrated by Dan Drown adding PPS capability to the CDC USB-UART bridge driver, as shared in a recent thread. Avoids having to muck around with the cables/connectors if a GNSS unit natively provides PPS on the CTS pin, as various units do.
NOTE: The GPSD client driver (type 46) uses the GPSD client protocol to connect and talk to GPSD , but using the SHM driver is the ancient way to have GPSD talk to NTPD . There are some tricky points when using the SHM interface to interface with GPSD , because GPSD will use two SHM clocks, one for the serial data stream and one for the PPS information when available. Receivers with a loose/sloppy timing between PPS and serial data can easily cause trouble here because NTPD has no way to join the two data streams and correlate the serial data with the PPS events.
pfSense uses NTPD and the configuration GUI does not allow custom options.
Sure you can manually change the ntpd.conf file, but it will not persist on NTPD restart, reboot, or pfSense upgrade.
NTPD NMEA drivers support both NMEA messages and PPS in the same driver. I’ve had a Garmin GPS receiver connected to my pfSense firewall more than a year without issues.
time1 PPS offset to account for any electrical or interrupt delay.
time2 NMEA message offset from PPS, length, and baud rate.
flag1 enable PPS.
flag3 enable kernel PPS discipline.
Plotted loopstats clock offset over 24 hour period. Garmin GPS 18x sitting on a an interior window ledge, so not getting full sky view. Seems good enough for my homelab.
I would min/max-poll at 1, there is no reason to let it poll at 2^4.
Poll 1 is every 1~2 seconds, your computer has no problem doing that.
Every 16 seconds will fill the buffer with a lot of data and that takes time to collect and process.
I suggest you change 4 to 1 for better results.
Also, I would remove time1, the PPS is so fast, if you correct it you make it more in-accurate…in my opinion. As it’s typical in the nanosecond range already.
pfSense WebGUI lowest poll setting is 3 (8 sec), default is 4 (16 sec).
If I set time1 to 0, NTPD will use a time.nist.gov pool source for time data, although it will still report GPS stratum 1 served to clients. (ntpq -c sysinfo)
IMHO, it’s about low jitter and adding a firewall rule to force all clients to use the local NTP server vs reaching out to the internet for time which will have several orders of magnitude higher offset and jitter.
