gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary E. Miller
Subject: Re: [gpsd-users] Disable or restart PPS in gpsd?
Date: Thu, 4 Sep 2014 12:02:12 -0700

Yo Alexander!

On Thu, 04 Sep 2014 06:18:36 -0700
Alexander Carver <address@hidden> wrote:

> On 2014-09-04 01:11, Gary E. Miller wrote:
> > 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.
> 
> ATOM is the Type 22 refclock.  It listens for the PPS notices on the
> pps device.

So just the ntpd PPS only reference clock?

> >> 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.
> 
> It seems to be possible for OpenBSD.  In fact the documentation I've
> found online suggests ldattach followed by gpsd in many cases.

The way the KPPS RFC works on BSD is only vaguely similar to how it
works on Linux.  And since gpsd does not support KPPS on OpenBSD not
relevant at all to linux. 

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

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

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

> So that's also where I seem to be stuck.  If I allow pps0 to be
> created by gpsd, then I can read the GPS data through gpsd not just
> for ntpd but for other programs as well and ntpd still has access to
> pps0.  If I use ldattach to create pps0 independently, then gpsd has
> no access to ttyS0 to get any GPS data.

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]