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:

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.

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

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: