Gps receiver & ntp
-
$ 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.
-
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
-
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=5Then 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=5This 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 jitterGPS_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.924But 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 updatesConfused
Andrew
-
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
