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

[Gary E. Miller]

Yo Alexander!

On Wed, 03 Sep 2014 17:22:22 -0700
Alexander Carver <address@hidden> wrote:

> > gpsd never uses ldattach.  Port sharing of a GPS is problematic as 
> > autobaud and auto configure will get confused between two GPS
> > clients.
> > 
> > Just have ntpd read the GPS by way of gpsd.
> 
> You misunderstand.  I need the pps device to allow ATOM to work.

I do not know what ATOM is.

> The
> other times are coming in from SHM(0).  So the GPSr is being read by
> gpsd and passed over but the PPS portion just doesn't work well so I
> need to share that single port with pps0 for ntpd and the rest (ttyS0)
> for gpsd.

I still do not think that is possible, maybe if you write a shim.

> I'm not asking ntpd to do anything with the port.  I'm not
> using the NMEA driver, I'm using ATOM.  The GPS isn't even NMEA, it's
> SiRF.

Really no benfit to using a SiRF in binary mode for time.  And since
the SiRF binary sometimes needs a handshake doubly hard to duplex.

> > 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.

>  There's no config file
> for gpsd as you're very well aware.  It starts and goes and nothing
> else to do.  For ntpd, I point it at SHM(1) and it should collect
> data.  It does collect data (assuming ATOM is disabled, of course)
> but the jitter is bad.  If I do not use SHM(1) and stick to ATOM, the
> jitter is much better.

Which is all very odd.  I have never seen or heard of bad SHM(1) results
like you say you are getting.

> >> Right now, SHM(0) isn't even reporting, gpsd is spewing KPPS
> >> errors, but ntpd's ATOM is happily ticking away with 1 microsecond
> >> jitter and less than 5 microseconds offset.
> > 
> > Likely because only one can use the port at a time.
> 
> Well yes I understand that to an extent.  SHM(0) plus ATOM actually
> does work.  It's SHM(1) that has trouble which is why I'm using ATOM
> in the first place.  ATOM does far better with jitter than SHM(1).
> SHM(0)'s jitter is going to be bad since it's just the time stamps
> from the GPS itself without the aid of the PPS as that comes in by
> SHM(1).

Yes, all SHM(0) is good for is coarse adjustment.  The SHM(1) should
be riock stable.

> > You gotta pick ntpd or gpsd to run the GPS.  You can't share and get
> > good timing.
> 
> I'm not picking ntpd to run the GPS.  I'm using gpsd to run the GPS.
> But gpsd is giving me terrible results for PPS via SHM(1) so I must
> resort to having ntpd listen to pps0 using ATOM.  I'm still using
> SHM(0) to get the regular GPS clock data for seconds numbering.  This
> is not an abnormal configuration, it's discussed many times in
> various places but PPS via gpsd is just not doing well in terms of
> stability.  PPS via the pps0 device and sent to ntpd directly via
> ATOM does work fine.

Then why do you need gpsd at all?  And if it is fine, there is no problem?

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