[SOLVED] Serial GPS NTP Displays Incorrect Source on Dashboard
-
@stephenw10 said in Serial GPS NTP Displays Incorrect Source on Dashboard:
There are two tabs on the NTP settings. The PPS tab is usually not used for a GPS source since PPS is enabled on the GPS tab by default.
That's what I have enabled. PPS on the Serial GPS tab and not the separate PPS tab.
-
Ok, then you may need to tweak the fudge values so the offset is low enough.
ntp is a fickle beast though! It might just appear to be doing that. Try not configuring any external servers. Does it still sync?
-
This is the output I see. What do I need to tweak?
[2.6.0-RELEASE][root@redacted]/root: ntpq -c kerninfo associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern, pll offset: -1.4569 pll frequency: -20.8333 maximum error: 9.857 estimated error: 0.032 kernel status: pll ppsfreq ppstime ppssignal nano pll time constant: 4 precision: 1e-06 frequency tolerance: 495.911 pps frequency: -20.8333 pps stability: 4.87634 pps jitter: 0.011 calibration interval 256 calibration cycles: 41 jitter exceeded: 46 stability exceeded: 0 calibration errors: 5 [2.6.0-RELEASE][root@redaced]/root: ntptime ntp_gettime() returns code 0 (OK) time e7e0825d.fc0a6b94 Tue, Apr 11 2023 21:05:33.984, (.984534236), maximum error 3222 us, estimated error 42 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -1440.389 us, frequency -20.833 ppm, interval 256 s, maximum error 3222 us, estimated error 42 us, status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, pps frequency -20.833 ppm, stability 4.876 ppm, jitter 11.503 us, intervals 41, jitter exceeded 46, stability exceeded 0, errors 5. [2.6.0-RELEASE][root@redacted]/root: ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 -1.476 0.508 time.nist.gov .POOL. 16 p - 64 0 0.000 +0.000 0.000 +utcnist2.colora .NIST. 1 u 22 64 377 55.943 +0.397 1.938 *time-e-wwv.nist .NIST. 1 u 25 64 377 54.777 +0.032 1.944 +time-e-b.nist.g .NIST. 1 u 22 64 77 50.584 -2.255 0.752If I block outbound pools, it seems to sync and will report .GPS. (stratum 0, PPS)
[2.6.0-RELEASE][root@redacted]/root: ntpq -c kerninfo associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern, pll offset: -0.261249 pll frequency: -20.7932 maximum error: 6.5 estimated error: 0.008 kernel status: pll ppsfreq ppstime ppssignal nano pll time constant: 4 precision: 1e-06 frequency tolerance: 495.911 pps frequency: -20.7932 pps stability: 4.64194 pps jitter: 0.003 calibration interval 256 calibration cycles: 46 jitter exceeded: 50 stability exceeded: 0 calibration errors: 6 [2.6.0-RELEASE][root@redacted]/root: ntptime ntp_gettime() returns code 0 (OK) time e7e087e2.c4db2704 Tue, Apr 11 2023 21:29:06.768, (.768969647), maximum error 4000 us, estimated error 5 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -221.215 us, frequency -20.793 ppm, interval 256 s, maximum error 4000 us, estimated error 5 us, status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO), time constant 4, precision 0.001 us, tolerance 496 ppm, pps frequency -20.793 ppm, stability 4.642 ppm, jitter 3.252 us, intervals 46, jitter exceeded 51, stability exceeded 0, errors 6. [2.6.0-RELEASE][root@redacted]/root: ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 11 16 377 0.000 -0.204 0.070 time.nist.gov .POOL. 16 p - 64 0 0.000 +0.000 0.000 time-a-wwv.nist (loop) 2 u 137 64 234 0.163 -0.968 1.053 time-e-wwv.nist (loop) 2 u 3 64 143 0.140 -0.114 0.545 -
The jitter there seems high for something with PPS. I expect to see <0.01ms as you showed earlier.
You can see the offset is still larger than some remote servers so ntpd is using those. You probably need to adjust the fudgetime2 value to bring it down.
Unfortunately my own gps failed a while ago when my cat destroyed the antenna
so I only have old data to refer to like this:[2.5.0-DEVELOPMENT][root@2220.stevew.lan]/root: ntpq -c cv associd=0 status=0021 2 events, clk_no_reply, device="NMEA GPS Clock", timecode="$GPGGA,190002.000,xxxx.xxxx,N,xxxx.xxxx,W,2,10,1.13,97.4,M,47.0,M,0000,0000*4D", poll=49689, noreply=1, badformat=1, baddata=0, fudgetime2=550.000, stratum=0, refid=GPS, flags=7 [2.5.0-DEVELOPMENT][root@2220.stevew.lan]/root: ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 6 16 377 0.000 -0.006 0.001 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 -213.251.53.217 193.0.0.229 2 u 56 64 277 6.824 -0.226 0.348 +85.199.214.100 .GPS. 1 u 11 64 177 7.250 -0.056 0.403 -time.videxio.ne 131.188.3.223 2 u 16 64 177 6.508 -0.393 0.235 -x.ns.gin.ntt.ne 249.224.99.213 2 u 19 64 27 5.535 0.231 0.323 +185.121.25.166 85.199.214.98 2 u 52 64 377 6.815 -0.140 0.326 -time.shf.uk.as4 129.250.35.250 3 u 22 64 77 9.020 1.393 0.185 +bronze.netweave 85.199.214.98 2 u 56 64 377 8.020 -0.126 0.156 +195.195.221.100 .GPS. 1 u 1 64 377 16.141 0.014 0.227I do have a USB GPS which works fine but has no PPS:
[23.01-RELEASE][admin@fw1.stevew.lan]/root: ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== *GPS_NMEA(0) .GPS. 0 l 3 16 377 0.000 -2.347 1.895 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 +0.000 0.001 -79-209.butt.spd 51.155.213.242 2 u 33 128 377 12.146 +24.507 10.064 +85.199.214.100 .GPS. 1 u 144 64 364 7.314 +23.577 1.440 +ntp.nat.ms 195.66.241.3 2 u 53 64 377 18.178 +25.346 1.021And hence bad jitter!
-
If I block outbound pools, it seems to sync and will report .GPS. (stratum 0, PPS)
In one of your pictures shown above you may be able to read something like, "Satellites in usage 8" (number of connected satellites)" so your gps is using that satellites
for grabbing time from.
Please see at the red arrow.
-
Here is the best write up I have read why there is an offset between the NMEA messages and PPS signal, and how to adjust the fudge 2 time to compensate for that difference. I am assuming the explanation is the same for the 16x and 18x.
https://support.ntp.org/Support/ConfiguringNMEARefclocks#Section_6.1.12.2
Obviously, one needs to infer the example ntp.conf settings to the fields in pfSense Serial GPS options. I am going to give it a try and see how well it works in practice.
-
BACKGROUND
I used the procedure at the following link to calibrate the NMEA messages vs PPS signal fudge 2 time. I also eliminated a 10' Cat5e extension cable with the hope of reducing the PPS jitter.
https://support.ntp.org/Support/ConfiguringNMEARefclocks#Section_6.1.12.2
SETTINGS
Baud Rate: 38400
NMEA Messages: GPGGA only
Fudge 1: 0.0
Fudge 2: 0.369
RESULTS
I am still getting some PPS sync error messages, but I think that is because the 16x is skipping some messages. I don't think it's a wiring quality or length issue.
Apr 13 14:02:30 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 14:05:58 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 14:32:22 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 15:22:30 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 15:30:46 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 15:39:50 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 15:47:34 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 15:56:06 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded Apr 13 15:57:42 ntp ntpd[12395]: kernel reports TIME_ERROR: 0x2307: PPS Time Sync wanted but PPS Jitter exceeded cat /dev/gps0 $GPGGA,[REDACTED],N,08007.2503,W,1,08,1.0,18.6,M,-28.7,M,,*48 $GPGGA,[REDACTED],N,08007.2503,W,1,08,1.0,18.6,M,-28.7,M,,*46 $GPGGA,[REDACTED],N,08007.2502,W,1,08,1.0,18.6,M,-28.7,M,,*45 $GPGGA,[REDACTED],N,08007.2502,W,1,08,1.0,18.6,M,-28.7,M,,*49 $GPGGA,[REDACTED],N,08007.2502,W,1,08,1.0,18.5,M,-28.7,M,,*43 $GPGGA,[REDACTED],N,08007.2503,W,1,08,1.0,18.5,M,-28.7,M,,*49 <- blank LF here $GPGGA,[REDACTED],N,08007.2505,W,1,08,1.0,18.5,M,-28.7,M,,*4C $GPGGA,[REDACTED],N,08007.2505,W,1,08,1.0,18.4,M,-28.7,M,,*48 $GPGGA,[REDACTED],N,08007.2504,W,1,08,1.0,18.4,M,-28.7,M,,*41 $GPGGA,[REDACTED],N,08007.2504,W,1,08,1.0,18.4,M,-28.7,M,,*42 -
Mmm, looks better though.
-
For anyone who needs a Stratum 0 GPS+PPS source connected to pfSense, I have tested three different models of Garmin GPS receivers connected to appliances with a full DE9 RS232 port (PPS on DCD pin 1) and RJ45 COM port (PPS on CTS pin 8). Achieves less than 10 usec offset/jitter for less than $50 off evilBay.
Garmin models tested:
- GPS 16X LVS
- GPS 18X LVC
- GPS 19X HVS
-
Nice write up!
