On 2011-07-15, David Lord <[email protected]> wrote: > Michael Eder wrote: >> Again we are talking effectively what happens. There is a good deal of >> logic what to do if the NMEA and/or pps does not come in and if the system >> clock is significantly different from either the NMEA or pps. A whole day >> on the lab bench with a scope on both the pps and the NMEA these never >> happen. The pps comes in and by definition it must be represent the second >> + 1 of the previous NMEA string. This is exactly the same logic that gpsd >> uses and is why we tell NTP that the NMEA has an offset. >> >> We scope the oscillator also and it is a very expensive oceanographic device >> that adjusts for temperature automatically. >> >> >> Sounds like a common problem and I note when we add an additional network >> clock the problem seems to go away. >> >> I note there are multiple SHM segments in NTP. Anyone tried writing the pps >> time into two locations to fix this problem? > > Did you try my suggestion of marking the NMEA as prefer rather > than the PPS? > > server 127.127.28.0 minpoll 4 maxpoll 4 prefer > fudge 127.127.28.0 time1 0.680 refid NMEA > server 127.127.28.1 minpoll 4 maxpoll 4 > fudge 127.127.28.1 refid PPS > > instead of: > > server 127.127.28.0 minpoll 4 maxpoll 4 > fudge 127.127.28.0 time1 0.680 refid NMEA > server 127.127.28.1 minpoll 4 maxpoll 4 prefer > fudge 127.127.28.1 refid PPS
What are you feeding the shm with? Ie, what are you putting into the shm How do you deterime the "seconds" for the PPS? I would also make sure that the system did not think that nmea was a stratum 0 server, but jack its stratum up, so the system always thought that the PPS was a higher stratum than nmea. I am not sure why you would make nmea a preferred source? > > > David > > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of unruh >> Sent: Thursday, July 14, 2011 5:50 PM >> To: [email protected] >> Subject: Re: Single GPS/PPS time source gets marked as a >> falseticker >> >> On 2011-07-14, Michael Eder <[email protected]> wrote: >>> Not using gpsd, just writing the NMEA time and receive time into SHM >>> (0) like gpsd does. The pps does the same to SHM (1). Effectively >>> the pps code >> >> sounds like a bad procedure. You want to make sure that the nmea actually >> gets associated with the second marker that the interupt marks. >> Your nmea time will be off by 600ms from the true time, and could well >> confuse ntpd. >> >>> just increments the second from the NMEA string and writes it to SHM. >>> We need certain values from the NMEA string so have not looked into >>> anything but the ASCII strings. PPS comes in on a high priority >>> interrupt so it gets serviced very quickly. Actually the PPS >>> conditions an oscillator that we >> >> So when the pps comes in, you can read the system clock and you know how >> many usec the clock is out from true time-- you just do not know how many >> seconds. Then you can read the system time when the nmea comes in and >> determine how many seconds the system time is out from the true time (but >> not how many usec.) But combining the two, you can zero in on how many >> seconds and usec your system clock is out. >> >> interrupt-> read system time nnnn.uuuuuu >> nmea ---- rrrr at system time mmmm.vvvvvv >> >> d=(mmmm.vvvvvv-nnnn.uuuuuu)*1000000)/1000000 >> >> (d should be 0, since it should be within a second of interrupt) >> >> Then in the shm ntp packet, the sent and received times are nnnn.uuuuuu, and >> the remote received and sent are (rrrr+d).000000 where I am assuming that >> the time between the nmea packet and the pps interrupt is under a second-- >> ie the nmea sentence designates the time of the interrupt that is less than >> one second in the past. One could always throw the item away if d is not >> equal to 0. If, like in the Garmin 18x, the time of the nmea is close to a >> second late, then you could always put in a shift in defining d. >> d=int(mmmm.vvvvvv-nnnn.uuuuuu)*1000000.-500000.)/1000000 >> Ie, you want whatever writes into the shm to associate the nmea time with >> the pps time, and since (except for unusual circumstances) the system clock >> is assumed to keep reasonably good time (eg be out by not more than say >> 10000 PPM) you can use it as the flywheel to enable you to do that >> association. >> >>> use to keep time in the event we lose the GPS (out in the ocean on a >> buoy). >>> The tests I am running are in the lab so we are always getting the >>> NMEA and PPS. >>> >>> >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> Rob >>> Sent: Thursday, July 14, 2011 4:13 AM >>> To: [email protected] >>> Subject: Re: Single GPS/PPS time source gets marked as a falseticker >>> >>> Michael Eder <[email protected]> wrote: >>>> We have looked at our GPS on a scope, the PPS it is dead on and the >>>> NMEA (just one sentence) is also reliable with about a 680 ms latency >>>> and 10 ms jitter. >>> Again, are you using gpsd? >>> >>> If so, you may want to try removing the (huge) 680ms offset inside >>> gpsd instead of in ntpd. >>> There is a place in the code where a fixed offset is added to time >>> obtained using NMEA (because the gpsd author does not want >>> configurable items) and it cannot be correct for every possible receiver. >>> >>> Again, it is better to switch from NMEA to the native binary protocol >>> of the receiver. >>> >>> _______________________________________________ >>> questions mailing list >>> [email protected] >>> http://lists.ntp.org/listinfo/questions >> >> _______________________________________________ >> questions mailing list >> [email protected] >> http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
