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

unruh unruh at wormhole.physics.ubc.ca
Fri Jul 15 17:06:04 UTC 2011


On 2011-07-15, David Lord <snews at lordynet.org> 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: 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




More information about the questions mailing list