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

Michael Eder meder at whoi.edu
Fri Jul 15 21:05:22 UTC 2011


I think we are saying the same thing.  When the PPS comes in the NMEA value
in SHM is that of the previous second.

What works great is just the PPS alone (configure only one clock in
ntp.conf) and that may be the solution.  We can lose GPS but never PPS and
we condition the PPS time with the NMEA time values pps does not know when
we have a good NMEA string.  Our code is doing exactly (with regards to SHM)
what gpsd is doing, and I think gpsd recommended how to configure ntp.conf.
Will try setting NMEA clock to prefer per David Lord's suggestion next week
and report back.

Thanks for the help.

Michael Eder

-----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: Friday, July 15, 2011 10:39 AM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] Single GPS/PPS time source gets marked as a
falseticker

On 2011-07-15, Michael Eder <meder at whoi.edu> 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.  

No. By definition, the NMEA represents time of the last PPS that came in,
not the next one. Now, usually there is no difference, but if you loose PPS
for some reason, it could be important. 

Why have both nmea and pps delivered to the ntpd program. Why not have the
nmea associated with the pps immediately in the program which feeds the shm?



>
> 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?
>
>
> -----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

_______________________________________________
questions mailing list
questions at lists.ntp.org
http://lists.ntp.org/listinfo/questions





More information about the questions mailing list