Chris Kuethe wrote: > Hmf. Try this patch to ldattach
Thanks. This does make ldattach stay around, and I'm seeing data reported by gpsd, and the uncorrected NMEA timestamps (first shared memory area) are being seen and reported by ntpd. However, the PPS-corrected timestamps (second shared memory area) are still *not* being generated, as best I can tell. I tried running gpsd with the -D5 option (high debugging level), and there's no indication in the system logs of *any* PPS events. In particular, I'm not seeing any log messages in ntpshm.c starting with "ntpshm_pps". Even when I removed the "-t" option on the ldattach command -- which is supposed to cause the NMEA line discipline to base timestamps on the leading "$" of each block of sentences from the GPS (a sure way to generate pseudo-PPS events) -- I still didn't see any system log messages about PPS events. Note to Hal Murray: A "line discipline" is an additional processing layer invoked on a serial line. I've been trying several different OS'es and combinations of applications, and OpenBSD appears to have the most promise for my needs, mainly because PPS support is claimed to be built into the standard release's kernel (through the NMEA line discipline code). For ease of maintainability, I would prefer not to have to build a custom kernel to get PPS support -- which is what I would need to do if I use Linux or FreeBSD. Rich Wales [email protected] _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
