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

[Alexander Carver]

On 2014-09-04 12:02, Gary E. Miller wrote:
> 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?

Right, just PPS alone.  It relies on other refclocks or servers to count
seconds.


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

Ok, unfortunate but would have been nice.  Obviously that's not going to
change.


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

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

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.

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

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

Then I can't connect the kernel PPS (using ldattach) and still read from
the GPS because ldattach is blocking the serial port.

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 SHM(1) I have already stated is not working
properly but that's entirely internal to gpsd.  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.