[ntp:questions] ntpd + GPS + PPS + Linux (Ubuntu Lucid)

unruh unruh at wormhole.physics.ubc.ca
Thu Jun 9 15:19:46 UTC 2011

On 2011-06-07, Rob <nomail at example.com> wrote:
> Stephan Skrodzki <skrodzki at stevekist.de> wrote:
>> Am Mittwoch, den 01.06.2011, 16:35 +0000 schrieb Rob:
>>> > I am trying since some time to attach a SkyTraq Based GPS receiver to a
>>> > serial port + pps which "basically" works fine by using gpsd 2.92 and
>>> > ntpd 4.2.4p8.
>>> > a) can I use PPS there without the PPSAPI? I do not really want to build
>>> > a new kernel... having a short look it seems that there is no PPS
>>> > support for the SHM interface (anymore?)?
>>> gpsd plus ntpd does not require any PPS support in the kernel.
>>> there is no specfic PPS support via SHM but the gpsd just provides a
>>> pretty accurate clock to ntpd.  When your system is not overloaded
>>> (CPU loading always around or over 1.00) there should be no problem
>>> with sync
>> Overload is not the case. After what you wrote, I had a short look at
>> the gpsd ntpshm code and saw, that the pps shm part also inserts the gps
>> time from the gps, so: why do I need the gps part of the shm at all?
> I think you mean "the pps part..."
> The reason is that the gps interface is quite inaccurate.  The GPS
> unit sends an ascii string at some low baudrate every second, it contains
> the time of the last fix it derived from the satellite data.  There is
> often a varying delay between the time the fix was taken by the receiver
> and the moment it sends it to the serial port.
> Result is that time derived from this method can drift several hundreds
> of milliseconds.
> The gps receiver also sends a hardware pulse every second, and this is
> the signal used by the second shm interface, PPS.  It is much more accurate
> as the edge occurs exactly at the turn of the second, independent from
> the time of fix calculation.
> Of course the PPS alone is not enough to sync the clock because the pulses
> at each second do not tell what time of day it is.  Therefore there are
> two different shm segments, first the coarse one to lock into the time
> and then the fine one to lock to the exact turn of the seconds.

The garmin 18x LVM apparently has a problem that it will somtimes
deliver the nmea time aver 1 second after the pulse. This makes anything
think that that time is associated with t he wrong second. I believe the
latest gpsd has a fudge for this, but Garmin needs to get its act

>>> > b) could somebody hint me to a working ntp.conf for nmea gps + pps and
>>> > no external ntp servers?
>>> # SHM clock, requires running gpsd
>>> server minpoll 4
>>> fudge refid GPS
>>> server minpoll 4 prefer
>>> fudge refid PPS
>> this does not really work for me and leads to time resets every few
>> days... my unlucky guess is, that this is more related to gpsd than to
>> ntp.
>> What confuses me is the following behaviour with only 
>> server minpoll 4 maxpoll 4 prefer 
>> fudge refid PPS 
>> from syslog:
>> Jun  5 03:10:46 na-stephan ntpd[8583]: no servers reachable
>> Jun  5 03:11:02 na-stephan ntpd[8583]: synchronized to SHM(1), stratum 0
>> Jun  5 03:11:19 na-stephan ntpd[8583]: time reset -0.999972 s
>> Jun  5 03:12:29 na-stephan ntpd[8583]: synchronized to SHM(1), stratum 0
> This is a bit worrying.  It can be that gpsd has guessed the wrong
> time to relate to the PPS pulse.
> You have to know that the SHM interface cannot transfer raw PPS info.
> It can only transfer absolute time, which PPS does not deliver.
> Therefore gpsd uses a trick: when a PPS pulse arrives, it checks if
> the system clock is close to the seconds mark, and if so it sends
> the absolute time of the closest second.  When the system clock is far
> away from correct time, it could guess the wrong second.
> When I wrote that code, I set a maximum clock error of 400ms before
> the PPS SHM interface is "enabled".  As long as the clock is outside
> that margin, the PPS simply is dead and the GPS SHM interface (SHM(0))
> first has to "pull" the system within that margin.
> However, people had trouble with some receivers that had such bad
> accuracy on the serial protocol that the time never came within that
> margin (with external references also present), and the PPS never worked.
> So they increased this margin all the time.  I am no longer actively
> tracking what is happening with gpsd and I don't know what validation
> criteria are used now.
> Maybe you have become a victim of too loose enabling of the PPS
> interface and resulting wrong absolute time sent from gpsd to ntpd.
> That could easily result in +1/-1 second hopping of the clock.
> You could try raising the issue on the gpsd developer mailing list,
> they are quite active.

More information about the questions mailing list