Gps receiver & ntp

  • Rebel Alliance Developer Netgate

    I've found that using 3-4 NTP servers in addition to the GPS has made mine more likely to be used as the source.

    Also GPS signal quality can affect things as well.

    It's already set to prefer the GPS when possible but if it believes that the GPS is far enough off of reality, it can still be discarded.

  • Still confused.

    WE run with the GPS enables and and etc as NTP servers.

    It tooks about 2 hours to stop using local and switch to GPS as the timesource - worked solidly for about 48 hours and has now swapped to an internet time server even though GPS has by far the lowest jitter - what causes the swap (and how can I influence it?00



  • Can you post the output of ntpq -c pe and ntpq -c assoc?

    Without having a better idea of what NTP is reporting we could only guess, which is pretty pointless ;)

  • @andrew0401:

    Well spent a massive £19.95 on an unbadged USB GPS dongle, plugged it in - named the ports correctly in ESXi - rebooted the pfsense box - it found the GPS source and it started reporting status!

    The only slight surprise is that it seems very slow to choose the GPS source as the active peer - both GPS and the back up external NTP server are shown as "False Ticker" and it uses the local clock.

    Is there a way to make it choose the GPS source as a the preferred option if available or at least speed up the decision making process?

    Just to make clear, not after a super accurate clock, just that our internet links are so erratic that we cn be out of contact for a few hours at a time- so if the GPS holds us to less than 0.1 of a sec that would be enough.


    What GPS is this can you link the model?

    I find it interesting as mine runs half a second of normal time due to what i guess is the usb to serial conversion.

  • $ ntpq -c pe
        remote          refid      st t when poll reach  delay  offset  jitter

    xGPS_NMEA(0)    .GPS.            0 l  11  16  377    0.000  -533.88  1.737
    LOCAL(0)        .LOCL.          12 l    -  64    0    0.000    0.000  0.000    2 u  230  256  377  23.140  -2.786  0.806
    *    2 u  162  256  377  24.208  -2.528  0.843
    +ntp.oceanmediag      2 u  60  256  377  22.431  -2.508  0.433

  • ntpq -c assoc

    ind assID status  conf reach auth condition  last_event cnt

    1  890  915b  yes  yes  none falsetick              5
      2  891  8043  yes  yes  none    reject  lost reach  4
      3  892  961a  yes  yes  none  sys.peer              1
      4  893  941a  yes  yes  none  candidat              1
      5  894  941a  yes  yes  none  candidat              1

  • Yeah, that looks pretty clear, and the assoc output confirms that your GPS is being seen as a false ticker. The time is significantly off from the other sources (and the jitter twice as high), which is why it's being rejected. I'm pretty confident that it's because the GPS doesn't have PPS support.

  • Maybe a bad exaMPLE QUOTED


    $ ntpq -p
        remote          refid      st t when poll reach  delay  offset  jitter

    xGPS_NMEA(0)    .GPS.            0 l  15  16  377    0.000  -531.24  0.355
    LOCAL(0)        .LOCL.          12 l  74m  64    0    0.000    0.000  0.000    2 u  42  256  377  23.525    0.407  18.033      3 u  91  128  377  31.379    0.189  9.375
    +ntp1.exa-networ    2 u  128  128  377  29.922  -0.829  11.751
    *ntp.oceanmediag  2 u  108  256  377  22.060  -0.943  11.376

  • @Roots0:

    I have a cheap USB to serial NEMA GPS, and it runs at 500ms off decent time.

    See my original post and picture, could of saved your self the £.

  • The x still means that NTP sees it as a false ticker - again, the offset is quite far from everything else - about half a second if I remember my units correctly. Without PPS support I suspect you won't change the situation.

  • @Cry:

    Without PPS support I suspect you won't change the situation.


  • @jimp:

    We have PPS_SYNC in the pfSense kernel, and you can get PPS over serial with a hardware serial port.

    PPS needs GPIO not serial.

  • Rebel Alliance Developer Netgate



    We have PPS_SYNC in the pfSense kernel, and you can get PPS over serial with a hardware serial port.

    PPS needs GPIO not serial.

    (and many many other references to it working perfectly fine over serial…)

  • Found a cheap GPS board (by Sure Electronics) - gives 1PPS over a serial port (as well as having access via USB & bluetooth) - but seems to want to run at 9600 and to speak NMEA 3.0 - will this still be OK with pfsense ( have a vague memory or someone saying it needed to run at 4800??)


  • Netgate Administrator

    You mean this?
    That is quite cheap.


  • Yes - apparently no problem using in under win xp - might just take a  chance and spend the money.


  • Well I acquired the board from Sure - mixed results.

    Tried initially to just plug into pfsense - no luck at all - nothing.

    Built a Ubuntu server - added ntpd and gpsd - gpsmon and cgps both saw the datastream from the board but ntp did not see any output either PPS or NMEA - but became clear that in spite of what Sure say, the board is running at 9600 not 4800 and the supplied utility to change baud rate claims to work but the the card stays at 9600 - I wonder if this is why no luck with pfsense?  Is the port changeable to 9600 in pfsense?

    Also to help troubleshooting - can we get gpsmon (or similar) to prove whether any nmea data is being received

    Still playing


  • Netgate Administrator

    Hmm, I aquired a cheap USB GPS unit to test. It seems to be working.
    I am also seeing 'false ticker' but it doesn't seem that bad compared with other available peers:

    [2.1-BETA1][root@pfSense.localdomain]/root(10): ntpq -c pe
         remote           refid      st t when poll reach   delay   offset  jitter
    xGPS_NMEA(0)     .GPS.            0 l   10   16  377    0.000  152.398   3.583
     LOCAL(0)        .LOCL.          12 l  858   64    0    0.000    0.000   0.000
    +smurf.magicalfo     2 u   39   64  377    6.189  669.231   9.606
    +resntp-b-vip.lo   3 u   51   64  377    6.269  675.819   1.330
    *     2 u   48   64  377    9.317  676.426   1.610

    Also, most disappointingly, I am not seeing the latitude and longitude reported on the Status: NTP: page. Is that something I should see by default?


  • Rebel Alliance Developer Netgate

    That typically only shows up if the GPS is actually being used as the clock source. If it's marked "false ticker" then it's not being used as the clock source.

  • Netgate Administrator

    Hmm, OK. I did switch to using the GPS for a while but then went back. I'm wondering what sort of GPS signal the receiver is seeing in it's position next to the pfSense box. Probably not a great one.  It would be useful to look at the output directly as Andrew said above however gpsmon is only available as part of the gpsd package and that requires python which borked my Nano install.
    I guess I could always use a laptop to look at the signal quality.


  • Netgate Administrator

    For anyone else wondering what their GPS is outputting you can get that like so:

    [2.1-BETA1][root@pfsense.localdomain]/root(9): ntpq -c cv
    assID=0 status=0000 clk_okay, last_clk_okay,
    device="NMEA GPS Clock",
    poll=2767, noreply=0, badformat=0, baddata=0, fudgetime1=155.000,
    stratum=0, refid=GPS, flags=5

    Then feed that data, inside the "", into a converter website like:

    And a nice Google map is produced. I have fudged that data above because the actual output is astoundingly accurate, like within a few meters.

    I'm still not seeing a link on the status page though.  :-\


    Edit: Further reading shows that this value:


    Indicates the number of satellites being tracked. So I could probably do better than that.

  • Thanks for the way to get a response

    I get

    ntpq -c cv
    assID=0 status=0011 clk_okay, last_clk_17,
    device="NMEA GPS Clock",
    poll=13, noreply=1, badformat=0, baddata=0, fudgetime1=155.000,
    stratum=0, refid=GPS, flags=5

    This implies 9 satellites which should be enough for a good fix but I am still not getting a stable time even though the delay/offset/jitter are all better than an internet server.

    $ ntpq -p
        remote           refid      st t when poll reach   delay   offset  jitter

    GPS_NMEA(0)     .GPS.            0 l   11   16  377    0.000  126.915   1.686
    LOCAL(0)        .LOCL.          12 l  490   64  200    0.000    0.000   0.004
    *   2 u   17   64  377   21.539  667.288   3.924

    But just noticed this in the log (newest at top)

    Mar 15 13:29:27 ntpd[97143]: GPS_NMEA(0) flag1 1 but PPSAPI fails
    Mar 15 13:29:27 ntpd[97143]: refclock_ppsapi: time_pps_create: Inappropriate ioctl for device
    Mar 15 13:29:27 ntpd[97143]: GPS_NMEA(0) serial /dev/gps0 open at 4800 bps
    Mar 15 13:29:27 ntpd[97143]: Listening on routing socket on fd #28 for interface updates



  • Netgate Administrator

    That's to be expected if you are using a USB-serial converter since PPS cannot connect across it.
    Or are you using that development module?


  • Have been alternating sources - with varying results.

    Agree the USB module will never do PPS - but always connects and then after a few minutes goes to false ticker

    The Sure module is erratic - I can always connect to it using GPSD (GPSMON or CGPS) but connection to NTP is not as good - I have had a few occasions when it has connected via the NMEA datastream and then a few minutes later it is unable to connect.  No connection via PPS at all - though I believe that the voltages are at CMOS levels not RS232 - have seen a post somewhere about a n extra connection to be soldered onto the board to correct this - next weeks project!

    Shame - because on paper this seemed a very cheap way to get very accurate time!


  • @andrew0401:

    Agree the USB module will never do PPS - but always connects and then after a few minutes goes to false ticker

    Just to chime in here: Your issue is using USB. I tried to use a USB GPS on windows, and it always had a 500-600ms delay from the USB driver. No matter what, you're making a virtual serial port, and that will have delay.

    What you're seeing is exactly what I saw in windows: You get a good GPS signal first, so your clock resets to that. Then, ntpd notices that all of the other NTP servers listed are constantly 500-600ms faster than your GPS.

    It then takes the next logical step: If everyone else has the exact same time, but I have a source that is showing a time far from theirs, then it is a falseticker & will not be used for time sync. I confirmed with them over email that it supports 1pps

    As far as a dedicated GPS on the cheap, this is the best one I could find:

    I have not bought it yet, but will report back when I do. Note you have to buy the serial adapter separately, or roll your own. They include all the pinout info if you want to save $15 for the cable.

  • Update: I bought the GPS I mentioned, and even though I'm using direct serial, I also see a 500-600ms difference from GPS.

    This model supports 1PPS, but it doesn't appear PF is picking up on that.

  • Another note (and warning) about the MP-350P: The RS232 cableset that you can order with this does not include the 1pps connection according to the manufacturer. I'll need to make my own cable to do that.

  • Netgate Administrator

    Thanks for the warning.
    Better to cut off the custom/PS2 connector and wire on a DB9 plug you think? I guess you still need a 5V supply from somewhere.

    I'm still not seeing the Google maps link on the ntp status page even during the rare periods it decides to use the GPS signal. Anyone else seeing that?


  • One of the issues with most USB GPS's is they only output NMEA code once per second. I doubt the virtual serial port is adding that much delay all on itself, but there is probably a component related to that.

  • I am currently moving from Smoothwall (used for many years) to PFSense.  Doing some different stuff with PFSense with multiple WAN and LAN connections such that I built a new box with 6 NICs on it.  Its on its own dedicated hardware box right now.

    The above said.  I have been using an NTP server with a GPS for a few years now.  I would like to shut that box down and attach the GPS to the PFSense server.

    Over the years have used a variety of GPS hardware devices all serially connected.  First one was just mounting a GPS antenna outside and a serial receiver inside (old surplus vehicle one).  I then went to the Sure Electronics one (which did OK until it burned up one day) and currently using an older style GPS with a serial connection on it mounted in the attic with a serial wire run some 3 floors into the basement.

    Concurrently I am into weather and amateur radio such that I am adding an APRS Station to my setup and playing around a bit with doing direct satellite weather map downloads from NOAA satellites.

    Serially right now this is what I see on my NTP box running my some 100 foot serial cable to the comm closet.


    I am documenting my PFSense build on an automation forum; going really slow with it.  That said is there a step by step anywhere here on the forum or wiki such that I can add my hardware GPS to the PFSense NTP server?

    Here is where I am posting my PFSense build:

  • Rebel Alliance Developer Netgate

    To enable GPS on pfSense 2.1 it's just a matter of going to Services > NTP, and selecting the serial port on which the GPS sits. Nothing else to it, no knobs or anything.

  • How is this installed?



  • Very knowledgeable and very interesting.

Log in to reply