Gps receiver & ntp
-
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
-
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 ;)
-
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 jitterxGPS_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 -
-
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 jitterxGPS_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 -
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.
-
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.
-
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
-
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
-
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.610Also, 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
-
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.
