Gps receiver & ntp



  • Wondering about putting a cheap gps receiver onto the pfsense box so as to create a more stable time source ( based at a rural location and internet is slow and unreliabe) - any recommendations as to a good receiver to use?  Pfsense is running on in an ESXi box if it makes any difference.

    Thanks

    Andrew


  • Rebel Alliance Developer Netgate

    There are a couple other threads around where people have given at least one model number of a device, but I'm not sure if very many people have tried it.

    It works for me, though the device I have leaves a bit to be desired in accuracy.

    In theory it should work with any device that outputs NMEA data over serial, preferably an actual serial connection and not USB-to-Serial.



  • Ideally you want one that supports a PPS signal for an accurate time sync.


  • Rebel Alliance Developer Netgate

    PPS over physical serial, yes.

    PPS over USB isn't feasible, last I read. The timing of the bus isn't accurate enough to guarantee the signaling in the same way that a physical serial port can.



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




  • Maybe a bit offtopic, but I remember I read something about GPS, UTC and the atomic clock not beeing in sync cause of leap seconds.

    How does that work when you sync with both GPS and NTP? Do you get excact local time anyway, or will your server drift back and forth several seconds?

    http://leapsecond.com/java/gpsclock.htm



  • Many NTP servers use GPS for their time sync, all you're doing is cutting out the middle man as it were.

    The NTP protocol uses UTC and includes leap seconds. GPS time sources don't include the leap seconds, but they do include the offset from UTC so it's easy for receivers to work out the UTC time, which the NTP daemon will then use.

    In short, it's all handled transparently for you and you don't have to worry about it.



  • Just for fun, I've been looking at building a GPS-based NTP server using this equipment (sans breadboard):

    http://www.adafruit.com/blog/2012/11/16/raspberry-flavored-time-a-ntp-server-on-your-pi-tethered-to-a-gps-unit-piday-raspberrypi-raspberry_pi/



  • @biggsy:

    Just for fun, I've been looking at building a GPS-based NTP server using this equipment (sans breadboard):

    http://www.adafruit.com/blog/2012/11/16/raspberry-flavored-time-a-ntp-server-on-your-pi-tethered-to-a-gps-unit-piday-raspberrypi-raspberry_pi/

    Great article. It shows you why can't you do that built-into pfSense, especially inside ESXi.

    • you need hardware GPI port to get into the system the PPS signal
    • you need modified kernel to be able to process in nanoseconds time the PPS signal

    But nevertheless you can build the whole box as described with a PI. I'd just mount it in a waterproof box and add PoE support and place the whole thing on the roof for the best GPS signal…


  • Rebel Alliance Developer Netgate

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

    So you can do it on pfSense, it just requires the proper hardware.



  • 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.

    Andrew


  • 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 0.uk.pool.ntp.org 1.uk and 2.uk 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

    Thanks

    Andrew



  • 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.

    Andrew

    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
    +ntp.demon.co.uk 195.66.241.10    2 u  230  256  377  23.140  -2.786  0.806
    *dns0.rmplc.co.u 195.66.241.2    2 u  162  256  377  24.208  -2.528  0.843
    +ntp.oceanmediag 192.93.2.20      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

    THIS IS MORE TYPICAL

    $ 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
    +ntp.demon.co.uk 195.66.241.10    2 u  42  256  377  23.525    0.407  18.033
    -time.shf.uk.as4 82.219.4.30      3 u  91  128  377  31.379    0.189  9.375
    +ntp1.exa-networ 33.117.170.50    2 u  128  128  377  29.922  -0.829  11.751
    *ntp.oceanmediag 193.190.230.66  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.

    Agree.



  • @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

    @robi:

    @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.

    Nope.

    http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
    http://gpsppssync.sourceforge.net/
    http://lists.ntp.org/pipermail/questions/2007-December/016485.html
    http://mail-index.netbsd.org/current-users/2012/08/10/msg020838.html
    (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??)

    Andrew


  • Netgate Administrator

    You mean this?
    http://www.sureelectronics.net/goods.php?id=99
    That is quite cheap.

    Steve



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

    Andrew



  • 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

    Andrew


  • 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 195.66.241.2     2 u   39   64  377    6.189  669.231   9.606
    +resntp-b-vip.lo 110.116.250.33   3 u   51   64  377    6.269  675.819   1.330
    *dns0.rmplc.co.u 195.66.241.3     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?

    Steve


  • 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.

    Steve


  • 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",
    timecode="$GPGGA,120907.000,5235.8155,N,00008.0380,W,1,06,2.5,101.0,M,47.0,M,,0000*44",
    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: http://www.gonmad.co.uk/nmea.php

    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.  :-\

    Steve

    Edit: Further reading shows that this value:

    $GPGGA,120907.000,5235.8155,N,00008.0380,W,1,06,2.5,101.0,M,47.0,M,,0000*44

    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",
    timecode="$GPGGA,133300.000,5245.0772,N,00056.8106,E,1,09,1.2,67.9,M,47.0,M,,0000*64",
    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
    *ntp.demon.co.uk 140.203.204.77   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

    Confused

    Andrew


  • 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?

    Steve



  • 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!

    Andrew



  • @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: http://www.usglobalsat.com/store/download/58/mr350p_ds_ug.pdf

    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?

    Steve



  • 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.


Log in to reply