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

unruh unruh at wormhole.physics.ubc.ca
Thu Jul 14 21:50:25 UTC 2011


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




More information about the questions mailing list