[ntp:questions] GPS NMEA source falseticker after few days...
Hi guys and girls, I have a problem with a GPS device. It is flagged "falsetick" by ntpd. It worked well for a few days but it stays as a falseticker since "Jun 23 14:19:15". I have 2 devices in LAN: - the device 1 (192.168.1.1) has a GPS (GARMIN G-16x HVS) connected to it and a ntpd server with this configuration: tinker panic 0 server 127.127.20.0 mode 1 prefer fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 time2 0.600 statistics peerstats loopstats statsdir /var/log filegen peerstats file ntpd.peers.log type none nolink enable filegen loopstats file ntpd.loops.log type none nolink enable - the device 2 (192.168.1.3) has a ntpd server with this configuration: tinker panic 0 server 192.168.1.1 iburst statistics peerstats loopstats statsdir /var/log filegen peerstats file ntpd.peers.log type none nolink enable filegen loopstats file ntpd.loops.log type none nolink enable With ntpq software, I've got these information about the ntp server 192.168.1.1: - # ntpq 192.168.1.1 ntpq> pe remote refid st t when poll reach delay offset jitter == xGPS_NMEA(0) .GPS.0 l 21 64 3770.000 -93.417 0.019 ntpq> as ind assid status conf reach auth condition last_event cnt === 1 19198 9144 yes yes none falsetick reachable 4 ntpq> rv 19198 associd=19198 status=9144 conf, reach, sel_falsetick, 4 events, reachable, srcadr=GPS_NMEA(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00, stratum=0, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=GPS, reftime=dd07801f.17eafe6a Wed, Jul 5 2017 17:11:27.093, rec=dd078020.30f1b22b Wed, Jul 5 2017 17:11:28.191, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=0, flash=00 ok, keyid=0, ttl=1, offset=-93.417, delay=0.000, dispersion=0.941, jitter=0.019, filtdelay= 0.000.000.000.000.000.000.000.00, filtoffset= -93.42 -93.41 -93.41 -93.41 -93.41 -93.41 -93.39 -93.38, filtdisp= 0.020.981.942.903.864.825.786.74 ntpq> clockvar associd=0 status=00f2 15 events, clk_bad_format, device="NMEA GPS Clock", timecode="$GPRMC,151202,A,4649.1519,N,00630.1749,E,002.1,352.5,050717,001.3,E*7A", poll=19345, noreply=18, badformat=8950, baddata=0, fudgetime2=600.000, stratum=0, refid=GPS, flags=5 - As you can see, the source GPS_NMEA is flagged "falsetick". And, I don't understand why. I read the page https://www.eecis.udel.edu/~mills/ntp/html/select.html and several posts in the mailing list but I don't find relevant information for my case. We can see "clk_bad_format" status in the clockvar command return. Can be an explanation of the falsetick or there is a cryptic value that is too high that I need to mitigate with tos mindist or something like that ? Maybe the GPS didn't receive some NMEA packets at one point (I put the GPS device inside my home while it was raining). Can be an explanation why ntpd think is not a reliable time source since then ? The GPS device has a clear view now but nothin change. The source remains a falseticker. When a source is flagged flaseticker, can it not become a truechimer again ? I would appreciate some advices about this problem. Regards, Anthony. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS-PPS, standalone server. NTP
On 2017-07-06, Fida Hasan wrote: > >> >> You mean that the fluctuation in theoffset if 1.6us. YOu have no way of >> knowing what the actual offset is, or do you have an independent clock? >> Ie, ntp could be adding 100ms to the time and you would not know it. >> (Not that that would be likely but 2 or 3 usec could be likely) >> > > Thanks William! You are right. NTP adjustment and mitigation loops play a > role in this part. > I made a straightforward experiment with two Rpi that are sync with two > individual GPS with an offset of 1.6 micro (that what NTP shows) each. In P2P > mode I connected them through ethernet cable and gave one's address in > other's ntp.conf as a server while the node was sync with PPS-GPS in either > circumstance. Primarily I found their offset shows 20 microseconds! > It is interesting because theoretically, we know that gps is highly accurate > in ns level. Due to some hardware jitters, there might have some additional > offsets but they should not be larger like that. > I observed some experiments have been conducted in hardware level through a > direct connection with signal measurement instruments like the oscilloscope. > Those result shows the offsets between two gps receivers are around 100 ns! > So, the receiver I am using right now, I compared them using oscilloscope and > found similar offsets (100 ns). But they are as high as 20 micro in my RPi. The gps delivers a pps pulse to its output with an delay of something like 10-100 ns. Then the gps raises the PPS line, which is almost certainly not terminated properly so the pulse has an indetermnate rise time. Then the gpio triggers an interrupt at some point on that rise and it takes a while for the computer to page out what it is now doing and start he interrupt service routine. It then has to read out the time from the kernel. All of that takes time, time which is not accounted for. Basically the system says that the pps pulse occured when the clock is read out, which is of the order of a microsecond after the gps delivered the pps pulse to its output. To really get say 100ns precision, you need to compensate for all of those delays. They all have jitter as well (jitter which only increases the time delay, not decreases it-- eg the interrupts happen to be masked when the pulse actually comes in, the computer is busy in an non-interrruptable routine, etc. Ie to get into the ns regime you have to work hard on all those delays, and you will not get it from a RPi. Note that timing gps receivers will have a compensation for internal delays ( which apparently tend to look like staircases) which it can tell the computer about well after they have occured. So you can compensate for them after the fact. (PS it would be nice if youput line breaks ito your posts). > > So, along with NTP some other jitters are there. Now, my question, wheather > it is possible to command NTP to stop adjustment only say to fix the GPS PPS > with the system clock. If it is possible then I can understand how accurately > Rpi can produce GPS PPS signal! > > >> >> The shm drive is one way. Another is the pps driver >> >> Make sure that you have the >> timepps.h header file somewhere. You have to find it somewhere . >> If you have it, and you make chrony, it woill be built witht eh PPS API >> driver. >> Then before starting chrony and assuming you have the pps fed into the >> the serial port /dev/ttyS0, do >> modprobe pps-ldisc >> ldattach 18 /dev/ttyS0 >> >> Then in chrony.conf put >> refclock PPS /dev/pps0 >> >> and you should be set up. > > I followed your guide and tried with Chrony. Very unfortunately I can not > develop Chrony in my system. > Problems are: > > 1 If I install Chrony from repository (apt-get install chrony), I cant > interface it with PPS API, and I even don't find 'chronyd' daemon in my > system. > > 2. While trying to install manually > (https://chrony.tuxfamily.org/doc/3.1/installation.html), it gives make error! > > Completely stuck! > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
