On Jan 1, 12:38 pm, Evandro Menezes <[email protected]> wrote: > On Dec 31 2008, 8:49 pm, [email protected] wrote: > > > > > So, basically I'm manually adjusting the nmea second reading forward > > by 1. > > > The SHM(0) gps is still fudged to account for normal lag w/ the time > > given on qnan. Here's my conf with the modified gpsd: > > #Garmin GPS 18x LVC 0 > > server 127.127.28.0 minpoll 4 noselect #Local GPS serial > > fudge 127.127.28.0 time1 -0.420 refid GPSa > > How is this different from leaving the source code intact and fudging > the reference by +0.580? > > TIA
Evandro, because gpsd (and apparently LinuxPPS) have checks that lock it in to what it thinks is the 0 second boundary. I've tried to fudge it forward to the correct 0 second, but gpsd gives the error "not in locking range: 660123." So, it thinks it's 600ms away from the correct locking area, when it's actually ~0ms away. It's calculated the wrong second. There was a long thread in the gpsd mailing list where 2 developers were arguing on how to avoid this, and I think they either took it out completely or made some fix because the code didn't have the offset anymore. If you are using gpsd, and you set the clock exactly 1 second ahead while fudging nmea 1 second ahead with it, gpsd *shouldn't* send the pulse data because it will claim it's out of locking range. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
