NTP PPS False Ticker?
-
Mmm, tweaking the fudge times seems to have got me there though with a 3ms offset....
[2.5.0-DEVELOPMENT][admin@2220.stevew.lan]/root: ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 9 16 377 0.000 2.998 0.001 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 -ntp3.wirehive.n 195.66.241.2 2 u 46 64 377 12.833 1.890 0.440 -ams.aput.net 131.176.107.13 2 u 43 64 177 15.963 2.575 1.267 -jdrcomputers.co 206.189.118.143 3 u 38 64 225 10.913 -1.082 0.380 +ns1.do.steersne 195.66.241.2 2 u 111 64 176 11.381 3.048 0.231 -ntp1.wirehive.n 195.66.241.10 2 u 53 64 377 11.836 2.332 0.318 +68.183.253.148 85.199.214.102 2 u 112 64 332 11.772 2.819 0.233 +85.199.214.102 .GPS. 1 u 50 64 377 12.514 2.645 0.402 -fifi.m.faelix.n 90.155.74.42 3 u 47 64 373 18.100 1.513 0.176Hmm
-
That's looking better, did you have to do anything to get just one active peer? I ended up leaving the server alone for a couple of days at a time to 'settle' in between trying different things so maybe worth leaving yours a while and seeing how it fares.
-
afaik in the first screenshot of steve only the pps is taken from the GPS_NMEA, and the reference clock is taken from 85.199.214.100
false ticket maybe?
you restarted ntpd 2 hours ago but check now if you are still on one active peer or is back to the same situation
with if you can ntpq -crv -pn -
Yes I had assumed it was using the GPS only for PPS. I was never sure why though since the GPS always looks like a good source.
Still looks good now though apart from the offset. Not 100% sure what is offset from what though. Or why it doesn't correct if everything is showing an offset.
-
i had that problem on my raspberry pi with the gps hat, i solved it forcing my gps to send only $GPMRC and set the driver with server 127.127.20.0 mode 17 where 16 is for 9600bps and +1 for process $GPMRC only plus fudge 127.127.20.0 flag1 1 for the pps
-
Mmm, I'm using only GPGGA:
<gps> <type>MediaTek</type> <speed>16</speed> <nmea>2</nmea> <extstatus>yes</extstatus> <autocorrect_initcmd>yes</autocorrect_initcmd> <initcmd>JFBNVEsyMjUsMCoyQg0KJFBNVEszMTQsMCwwLDAsMSwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCoyOQ0KJFBNVEszMDEsMioyRQ0KJFBNVEszMjAsMCoyRg0KJFBNVEszMzAsMCoyRQ0KJFBNVEszODYsMCoyMw0KJFBNVEszOTcsMCoyMw0KJFBNVEsyNTEsOTYwMCoxNw0K</initcmd> <nmeaset> <gpgga>1</gpgga> </nmeaset> <port>cuau2</port> <fudge2>0.51</fudge2> <flag2>yes</flag2> <flag1>yes</flag1> <flag3>yes</flag3> <gpsminpoll></gpsminpoll> <gpsmaxpoll></gpsmaxpoll> <fudge1>0.003</fudge1> </gps> -
yes but your gps is sending out all the sentences, maybe?
i have this on my /etc/rc.local/bin/echo -e '$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n' > /dev/ttyAMA0 #diable all except GPMRCbut this is specific for my gps chip
so the output from my gps is like this
pi@raspberrypi:~ $ cat /dev/gps0 $GPRMC,204531.000,A,4520.6621,N,01147.2135,E,0.10,327.93,171219,,,A*69 $GPRMC,204532.000,A,4520.6622,N,01147.2135,E,0.18,330.45,171219,,,A*6C $GPRMC,204533.000,A,4520.6622,N,01147.2135,E,0.30,335.70,171219,,,A*64 $GPRMC,204534.000,A,4520.6623,N,01147.2134,E,0.26,347.73,171219,,,A*62there are probably other way to solve the problem, i think it's only a question of adjusting the timing between the pps and when your $GPGGA is "printed" on the serial port
with fudge 127.127.20.0 flag1 1 time1 -0.00300644 time2 0.470 refid GPS
i don't remember right now but i think that
tos mindist 0.100helped also
-
Mmm, nope it really is just sending GPGGA. That did help as otherwise it varies what is output making it impossible to tune pretty much. Also the location data is disturbingly accurate.
Have to play with this more when I have time.Steve
-
yeah, have fun with that when you have the time
-
Those micro-seconds all add up.
