M Z <[email protected]> wrote: > Hi. I have both usglobalsat MR350P and garmin 18xLVC connected to serial at > both > 4800 and 9600. > gpsd was 2.37 but is now 2.95. ntpd is 4.2.4p7, OS: SuSE 11.2 = 2.6.31. I > have > used both > serial ports. I set to low_latency as per instructions: > http://www.lammertbies.nl/comm/info/GPS-time.html > > gpsd 2.37 did not communicate with ntp for the pps (ntpq -p 'when' column > always > -). 2.95 seems to work ok. output looks good, xgps works (7 sats used), etc. > However, jitter seems large and offset, no matter how small to start (usually > +- > 20.) always creeps up to about -300 to -500.
There is a problem within gpsd that can bite you with some receivers. I originally wrote the code but I have not been paying attention lately and it may be that some things have changed. However the point is this: the PPS sent from gpsd to ntpd is sent via the second SHM interface. But via this interface to ntpd one cannot really send PPS information, only absolute time can be sent. But of course PPS does not convey absolute time. So the workaround I made in gpsd is to derive the absolute time from the NMEA or whatever binary messages sent by the receiver (and conveyed to ntpd via the first SHM interface). To do this, the moment the PPS line ticks has to be within a certain time from the moment the serial message arrives, I think this was coded at about 400ms, or the PPS pulse cannot be related to an absolute timestamp and it is rejected. The problem is that some receivers send a serial message timestamp that is way off the actual time, and the lock can never be achieved. It is possible to increase the locking range (and I think the current maintainers have done that already) but the risk is that the PPS pulse is associated with the wrong serial message and the PPS clock is off by one second. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
