Richard Cagley <rcag...@gmail.com> wrote: > On Tue, Jun 18, 2013 at 9:27 AM, Rob <nom...@example.com> wrote: > >> As I wrote before, your ntp config is not correct. please copy it >> from the docs. However, that is not the cause of the problem. >> (it would be the cause of severe inaccuracy once you obtain NMEA data >> as you are not using PPS) >> > > yeah, figured I'd walk before I ran so I tried to make my ntp.conf file as > simple as possible to at least get some timing info, which thanks to your > and AC's help I now have. > > ok, now onto pps. I went here > http://gpsd.berlios.de/gpsd.html > ...and am now using this as my ntp.conf > --- > server 127.127.28.0 minpoll 4 maxpoll 4 > fudge 127.127.28.0 time1 0.420 refid GPS > server 127.127.28.1 minpoll 4 maxpoll 4 prefer > fudge 127.127.28.1 refid GPS1 > --- > > But, sadly no pps sync... > --- > / # ntpq -p > remote refid st t when poll reach delay offset > jitter > ============================================================================== > *SHM(0) .GPS. 0 l 7 16 377 0.000 0.048 > 0.005 > SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 > 0.000 > --- > I have pps debug output built into the kernel and can see pps events on the > console while I look at gpsd output > --- > PPS event at 9862 > PPS event at 9962 > PPS event at 10062 > PPS event at 10162
Well, gpsd does not use kernel pps. It puts the pps time into the second SHM segment and lets ntpd pick it up there. This was coded in the days that Linux kernels often came without pps support and additional patches would have to be applied. I'm not too familiar with kernel pps or how you tell the kernel where to look for the pps, and if this can interfere with gpsd. Maybe gpsd has been updated to recognize kernel pps and stay out of the way, but it does not look like it in your debug log. (it still creates the pps thread) I would try removing the kernel pps config while you use gpsd, or only add it after it has been shown to work without it. > > Sorry, this is so long, but here's a dump of the gpsd output. There are > several things that concern me, such as some of the warning, but not sure > of the severity > > / # gpsd -bn -N -D5 /dev/ttyO0 > gpsd:INFO: launching (Version 3.7) > gpsd:IO: opening IPv4 socket > gpsd:INFO: listening on port 2947 > gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0 > gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1 > gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2 > gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3 > gpsd:PROG: shmat() succeeded, segment 131076 > gpsd:PROG: shared-segment creation succeeded, > gpsd:PROG: PPS thread launched > gpsd:INFO: NTPD ntpd_link_activate: 1 > gpsd:INFO: stashing device /dev/ttyO0 at slot 0 > gpsd:PROG: no etc/gpsd/device-hook present, skipped running ACTIVATE hook > gpsd:INFO: opening read-only GPS data source type 2 and at '/dev/ttyO0' > gpsd:PROG: PPS Create Thread gpsd_ppsmonitor > gpsd:PROG: PPS chrony socket /var/run/chrony.ttyO0.sock doesn't exist > gpsd:INFO: PPS cycle: 631139111, duration: 631139111 @ 1371576962.280231 Strang that this is the last that is heard from PPS, while in your earlier log there were a few PPS pulses that looked OK. (but then they were not used because no valid serial data was coming in) Did you change something? _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
