Feature #7193
closed
NTP process PGRMF
Added by Jack Booth almost 8 years ago. Updated about 7 years ago.
0%
Description
The Garmin only NMEA sentence PGRMF can be used by NTP as the time sync. Unlike the other NMEA sentences PGRMF includes leap second information that can be enabled in the NTP driver via the mode.
Updated by Jack Booth almost 8 years ago
Updated by
Updated by Jim Pingle almost 8 years ago
- Status changed from New to Feedback
- Assignee changed from Jim Pingle to Jack Booth
- Target version set to 2.4.0
PR merged
Updated by Pär Wedin over 7 years ago
I have the hardware to test this and I have enabled the "Process PGRMF" option, but I don't know what to look for. Can you give me a hint?
Updated by Jack Booth over 7 years ago
Pär Wedin wrote:
I have the hardware to test this and I have enabled the "Process PGRMF" option, but I don't know what to look for. Can you give me a hint?
If you have set the GPS to output PGRMF and have the option enabled you should be able to check the clockvar using 'ntpq -c cv' after ntpd has settled on the GPS device and see it used PGRMF in the timecode field. If the GPS is not the selected peer you need to check the clockvar of the correct association id, run 'ntpq -c ap' you should get something similar to:
remote refid assid st t when poll reach delay offset jitter
==============================================================================
+GPS_NMEA(0) .GPS. 12345 0 l 12 16 377 0.000 0.000 0.001
Then run 'ntpq -c "cv 12345"' and check the timecode field.
Updated by Pär Wedin over 7 years ago
In my original config I had GPGGA and PGRMF enabled and it seems that it prefers GPGGA then:
associd=30382 status=0012 1 event, clk_bad_format, device="NMEA GPS Clock", timecode="$GPGGA,183336,5854.4236,N,01756.9851,E,2,06,1.8,43.5,M,23.1,M,,*7F", poll=230, noreply=0, badformat=1, baddata=0, fudgetime2=700.000, stratum=0, refid=GPS, flags=5
From /var/etc/ntp.conf:
# GPS Setup server 127.127.20.0 mode 258 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0 time2 0.700 flag1 1 flag3 1
However, choosing all NMEA sentences plus PGRMF resulted in:
associd=13378 status=0042 4 events, clk_bad_format, device="NMEA GPS Clock", timecode="$PGRMF,914,335618,010317,211320,18,5854.4278,N,01757.0052,E,A,2,0,206,1,1*10", poll=440, noreply=1, badformat=3, baddata=0, fudgetime2=1675.000, stratum=0, refid=GPS, flags=5
Current /var/etc/ntp.conf includes:
# GPS Setup server 127.127.20.0 mode 256 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0 time2 1.675 flag1 1 flag3 1
I also had to change the fudge time2 with an extra second as the GPS source was exactly one second off for some reason.
I have a Supermicro A1SRi-2558F board with 8 GB of memory. The Garmin GPS 18x LVC is connected to cuau1. The pfSense build is from Mon Feb 27 02:08:42 CST 2017. I updated it to the new build this morning and I lost the connection to the gps as a result. The only way to get it back on was to roll back to the Feb 27 build, then it worked without a problem.
If you want me to run some more test then I'm happy to do so.
Updated by Jack Booth over 7 years ago
I also have a Garmin 18x LVC and I've been trying to replicate your setup but I'm not really sure why you needed a fudge time2 that high. What init commands are you using? Are you sure you are only getting GPGGA and PGRMF? You could try "cat /dev/cuau1" to confirm. I'm currently running 2.3.3p1 and seemed to have no issue with
# GPS Setup server 127.127.20.0 mode 256 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0 time2 0.535 flag1 1 flag3 1You could possibly try a different baud rate like 9600 but I'm not sure why you would need that if you have only set GPGGA and PGRMF.
Updated by Pär Wedin over 7 years ago
I'm sorry, I think I was unclear. In my original config I had selected GGA in the “NMEA Sentences” menu, plus ticked off “Process PGRMF” on the “Services/NTP/Serial GPS” page. That's when it seemed to select the $GPGGA sentence. But when I selected “All” in the “NMEA Sentences” menu, $PGRMF was selected.
In the configuration software for the gps I had selected GPGGA, GPGSA, GPGSV, GPRMC and PGRMF and 4800 baud. If I do “cat /dev/cuau1” I can see those sentences. To see what the issue might be I have tested that particular gps on two systems.
On the Supermicro A1SRi-2558F I'm now running 2.3.3-p1 and I get the following offset when using $PGRMF at different baud rates:
Baud rate | $PGRMF offset
----------+--------------
4800 | -1679
9600 | -879
19200 | -639
38400 | -517
On a Gigabyte Celeron J1900 system running 2.4.0-20170318 I get the following offsets for $PGRMF at different baud rates:
Baud rate | $PGRMF offset
----------+--------------
4800 | -1346
9600 | -1016
19200 | -612
38400 | -503
Clearly the offset becomes smaller as baud-rates increases but they are still large. Maybe I have a dodgy gps receiver.
Updated by Jim Pingle about 7 years ago
- Status changed from Feedback to Resolved
PR was merged, seems to be OK but not possible to confirm at the moment. If it is not working, someone can reply here and we can reopen the ticket later.