[ntp:questions] Single GPS/PPS time source gets marked as a falseticker

[David Lord]

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


David


> -----Original Message-----
> From: questions-bounces+meder=whoi.edu at lists.ntp.org
> [mailto:questions-bounces+meder=whoi.edu at lists.ntp.org] On Behalf Of unruh
> Sent: Thursday, July 14, 2011 5:50 PM
> To: questions at lists.ntp.org
> Subject: Re: Single GPS/PPS time source gets marked as a
> falseticker
> 
> On 2011-07-14, Michael Eder <meder at whoi.edu> 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: questions-bounces+meder=whoi.edu at lists.ntp.org
>> [mailto:questions-bounces+meder=whoi.edu at lists.ntp.org] On Behalf Of 
>> Rob
>> Sent: Thursday, July 14, 2011 4:13 AM
>> To: questions at lists.ntp.org
>> Subject: Re: Single GPS/PPS time source gets marked as a falseticker
>>
>> Michael Eder <meder at whoi.edu> 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
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions