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

[Alexander Carver]

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.

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

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

Right, they are awful coming through gpsd, they are great when using the
kernel's PPS mechanism directly (by way of the ATOM refclock).

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

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.

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.

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.

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.