Re: [gpsd-users] Unexpected behavior

[Nick Burkitt]

Hi Gary.

 

> Great.  Now file a bug report with Ubnutu for their broken binary.

>

When I have time to jump through the hoops. One could get the impression they don’t really want to hear about it.

 

> What is not clear?

> Add 'noselect' to the line with 'refid GPS'.

> Otherwise bad things happen.

>

That's clear. :-)

 

Unfortunately, things still aren't all sweetness and light in gps-land.

I am unable to get a cross-compiled application to survive a call to gps_open(), whether directly, or via a gpsmm object. It's instant segfault every time. I traced the problem to the call to getaddrinfo(). Google offers some hints, but I'm too far behind schedule now to start debugging glibc. I'll most likely just hack libgps to add a version of gps_open() that will take an IP address, and bypass getaddrinfo() entirely.

 

In the meantime, I'm concerned that ntpmon shows the jitter of the PPS ref clock in the tens to hundreds of microseconds, even after running continuously for 24 hours. I was expecting time errors no worse than one microsecond. The GPS module's PPS jitter is stated at +/- 11 ns.

 

     remote           refid      st t when poll reach   delay   offset   jitter

-SHM(0)          .GPS.            0 l   26   64  377      0ns -97.54ms 15.015ms

*SHM(1)          .PPS.            0 l   26   64  377      0ns -224.1µs 52.282µs

 

Is there more I need to do, or am I misreading things? Or did I misunderstand the accuracy claims?

Or is this why you suggested building KPPS into the kernel image, instead of  making it a loadable module?

 

Thanks again,

 

-Nick