On 2011-06-07, Rob <[email protected]> wrote: > Stephan Skrodzki <[email protected]> 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 togetehr. > >>> > 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 >> ntp. >> >> 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[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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
