On Tue, Jun 18, 2013 at 11:28 AM, Rob <[email protected]> wrote: > 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. > > 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? >
Yeah, it's a huge mystery to me how the kernel is getting pps info without me even telling it where the pin is. I can build in kernel pps support and debug output and see messages ever second on the console without ever explicitly doing an ldattach to /dev/ttyO0. I'm using the DCD pin, which I think is default. Maybe the kernel can generate it's own pps signaling, but I don't think it can. I'm using plain jane pps source out of the 2.6.37 kernel. The output you refer to may be partial. I do see lots of NMEA data. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
