pfSense

PR https://github.com/pfsense/pfsense/pull/3463

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?

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.

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.

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 1

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.