[ntp:questions] ntpd + GPS + PPS + Linux (Ubuntu Lucid)
nomail at example.com
Tue Jun 7 20:24:40 UTC 2011
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
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.
>> > 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 127.127.28.0 minpoll 4
>> fudge 127.127.28.0 refid GPS
>> server 127.127.28.1 minpoll 4 prefer
>> fudge 127.127.28.1 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
> What confuses me is the following behaviour with only
> server 127.127.28.1 minpoll 4 maxpoll 4 prefer
> fudge 127.127.28.1 refid PPS
> from syslog:
> Jun 5 03:10:46 na-stephan ntpd: no servers reachable
> Jun 5 03:11:02 na-stephan ntpd: synchronized to SHM(1), stratum 0
> Jun 5 03:11:19 na-stephan ntpd: time reset -0.999972 s
> Jun 5 03:12:29 na-stephan ntpd: 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