sleek daelite wrote:
Hi Rob,
Yeah i recompile my binaries of gpsd2.33. And i have pps enable. I
even ran ntpdc -c kern to check if my kernel had pps support.
But unfortunately im unable to achieve anywhere near micro second
accuracy. Could you possible let me know what softwares your using and
the contents of ur configuration file.
Cheers,
Allan
Allan,
When you are using gpsd together with ntpd, you do not use or need
kernel PPS. There is no need to look at those settings, or to use a
specially patched kernel.
gpsd is a user process which spawns a thread that waits on the PPS
signal change. When the signal changes, the thread takes the current
system time and writes it into a shared memory segment. For this, it
only needs the TIOCMIWAIT ioctl to be defined and working on the serial
port, which is true by default on Linux.
ntpd periodically reads this timestamp and steers the systemclock so
that the taken timestamps are as close as possible to the second marks.
The time steering is entirely done by ntpd and thus the kernel needs no
PPS support for this method.
The configuration that you need is like this:
/etc/ntp.conf should have two shared memory clocks defined, like this:
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 refid GPSa
server 127.127.28.1 minpoll 4 prefer
fudge 127.127.28.1 refid PPSa
(the fudge is only used to assign descriptive names to the clocks, they
can be omitted)
The first clock is written by gpsd with absolute time information
retrieved from the serial messages from the GPS receiver. This is the
initial (coarse) clock used for aquisition.
The second clock is written with the PPS timestamps, as described.
Because PPS can only be locking the clock to the nearest second, it is
not sufficient for acquisition of the absolute time.
You can also have other server lines in the configuration file, e.g. to
judge the achieved accuracy by comparing with external clocks.
gpsd has no configuration file but it should be started with the -n
option so that the receiver is always active, even when no other client
(like a navigation application) is connected to gpsd.
Like this: gpsd -n /dev/ttyS0
I start gpsd after ntpd, but it should not really matter in what
sequence they are started.
The result, after a while, should be like this: (ntpq -p)
remote refid st t when poll reach delay offset
jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 47 64 377 0.000 0.000
0.004
+SHM(0) .GPSa. 0 l 10 16 377 0.000 0.923
0.363
*SHM(1) .PPSa. 0 l 14 16 377 0.000 0.007
0.038
When the reach value of SHM(1) remains zero, the gpsd is probably not
seeing PPS pulses.
They should be connected to the DCD input of the serial port, polarity
does not matter and is autodetected by gpsd.
To see if pulses are detected, run gpsd at debug level 5 (gpsd -n -N -D
5 /dev/ttyS0). you should see messages like this:
carrier-detect on (device) changed to 0
carrier-detect on (device) changed to 1
This should occur every second.
Maybe the PPS pulses from your receiver are too short. I have several
receivers (all other types than you have) and while most have PPS pulses
of length like 50ms or 100ms, which works fine, there is one which
pulses for only 100ns.
This is too short for transmission via RS232. Such pulses should first
be lengthened.
I think other gpsd users are using the Garmin receiver with PPS, but I
am not sure.
Rob
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
