Re: [gpsd-users] Disable or restart PPS in gpsd?

[Gary E. Miller]

Yo Alexander!

On Thu, 04 Sep 2014 12:57:30 -0700
Alexander Carver <address@hidden> wrote:

> >>>>> Something wrong with your setup then.  No way gpsd adds 1000x
> >>>>> jitter. I routinely see around 1 microSec using gpsd and SHM().
> >>>>> Even better with chronyd.
> >>>>
> >>>> There's very little setup that could go wrong.
> >>>
> >>> Yes, but something is clearly wrong, those are aweful numbers you
> >>> see.
> >>
> >> Right, they are awful coming through gpsd, they are great when
> >> using the kernel's PPS mechanism directly (by way of the ATOM
> >> refclock).
> > 
> > So, we agree something wrong on your setup.
> 
> No, we disagree.  My setup as far as I can tell is just fine and
> matches pretty much everything documented on any site searchable by
> search engines.  SHM(1) is just doing a terrible job.  There's
> nothing I can configure in gpsd so there isn't anything for me to
> "setup" other than plug in the GPS and point gpsd at it.  The fact
> that ntpd is able to use the kernel PPS signal quite well on its own
> implies that everything starting from the GPS going up to gpsd is
> fine.  Once inside gpsd, something is not going well and SHM(1) is
> terrible.

Since many people use gpsd and SHM(1) with microSec jitter, and you
are the only outlier, I have to conclude something wrong on your end.

I suspect it is the effect of two GPS readers.  That is a very unusual
and previously unsuppoerted configuration.

> >> I need gpsd to read the GPS (because ntpd can't read a SiRF GPS)
> >> for seconds numbering when there are issues with the network.   It
> >> should be the first clock to use among all the clocks with the PPS
> >> keeping everything together.  It just isn't working in a variety
> >> of ways.
> > 
> > And since SiRF binary adds nothing, turn it off, problem solved.
> 
> Can't turn it off.  It's SiRF binary or nothing.  Aside from that I'm
> using data from other SiRF messages that are not available in NMEA so
> the GPS would have to stay in SiRF binary even if it was capable of
> NMEA.  This is the other reason for gpsd, the shared access to the
> GPS data.

What model?  We have never heard of a SiRF that can not run NMEA.

> >> When the KPPS error message shows up, gpsd turns off SHM(0)
> >> entirely. It never turns back on.  I have to restart gpsd to make
> >> that work but, because of gpsd controlling the existence
> >> of /dev/pps0, I have to also stop and restart ntpd or it won't be
> >> able to see pps0.
> > 
> > Yeah, the GPS stream got hosed.  So don't do that.
> 
> How about turning SHM(0) back on once the stream comes back?  The
> stream never died.  The only thing that happens is poor satellite
> coverage (one or two good satellite signals at most).  Everyone is
> going to lose signal at some point, that's a given.  But to force the
> need to restart all of gpsd when it really should start serving time
> again once the time is available seems harsh.  You do it at startup,
> why can't it warm start itself after the stream returns?

Well, that is a new data point, you did not say you had bad sky coverage.
That is the first step to good time.  And I have never seen SHM(0)
not recover after bad sky conditions.  SO once again an outlier here.

> > Yup, one or the other, that is how the RFC works, exclusive access.
> > 
> >> One thing to note, when SHM(0) stops working, the TCP/IP port on
> >> gpsd is still fine and gpsd is still reading data from the GPS.  I
> >> can get position data, satellite data, etc. all from the socket.
> >> It just stops updating any of the SHMs unless I restart gpsd.
> > 
> > So, back to my original thought, compile gpsd wwithout KPPS.
> 
> Then I can't connect the kernel PPS (using ldattach) and still read
> from the GPS because ldattach is blocking the serial port.

Well, then you are hosed, because while gpsd does not use ldattach, it
uses the same system call as ldattach.  So there should be no difference
in how the serial port works. 
 
> I would probably be fine if SHM(0) would actually come back on its own
> without user intervention.  Without that it can't be used as a
> preferred peer for either SHM(1) or ATOM(PPS) because if it dies, it
> takes the whole system out.

And that is just weird, never seen that before either.

>  And SHM(1) I have already stated is not
> working properly but that's entirely internal to gpsd.

I disagree, many people have it running many places very well, and no
complaints until now.

I suggest at a minimum you compile the latest release.

>  There's no
> knob for me to twiddle to fix either problem.  I can't make SHM(0)
> come back without forcibly restarting gpsd and there are no
> adjustments to make to gpsd that fix the jitter in SHM(1).  The
> kernel on its own and using ntpd's PPS driver performs extremely well
> but if I trade out the PPS driver for SHM(1) the jitter is poor.  So
> the data coming from SHM(1) is just poor in general but the PPS
> signal is clean and the jitter on it is very low.

Which comes back to something wrong with your setup since others do
not see results like you are getting.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588