Re: [gpsd-users] syslog error message with new version - kernel PPS failed Connection timed out

[hans mayer]

Yo Gary,

I see there is a big leak in my knowledge about
gpsd, kernel pps and ntp. I am sure you can help.

For easy reading I pick out the relevant parts.
I hope this is convenient.


> But you fail to mention how you enabled /dev/pps0.

I put a line with "pps-gpio" into /etc/modules
and file /etc/modprobe.d/pps-gpio.conf has:
options pps-gpio gpio_pin=18
and after a reboot it was there and available for ppstest


>> and NTP also working fine with PPS/ATOM support 127.127.22.0
> Using what config?

# Enabling PPS/ATOM support
server 127.127.22.0 minpoll 5 maxpoll 6
fudge 127.127.22.0 refid PPS time1 -0.0053
fudge 127.127.22.0 flag3 1  # enable kernel PLL/FLL clock discipline

# gpsd shared memory clock
server 127.127.28.0 minpoll 5 maxpoll 6 prefer  # PPS requires at least 
one preferred peer
fudge 127.127.28.0 refid GPS
fudge 127.127.28.0 time1 +0.110  # coarse processing delay offset
#


>> And how ?
> By opening /dev/pps0

hmm ??
I thought NTP is doing this.
But obviously there are at least 2 methods to do it.
But this error message is also coming without running NTP.
So it's not a thing of "you are not allowed because I do"


> And your confusion is?

The error message itself: ERROR: KPPS:/dev/ttyS2
What has ttyS2 to do with kernel PPS ?
ttyS2 is RxData pin and the kernel PPS is generated in my case out of
GPIO pin 18, which is a different pin.
So how to interpret this message: ERROR: KPPS:/dev/ttyS2 ?


> Since gpsd is outputting the KPPS error you obviously built with pps=yes.

This is the default. So the answer is yes.


>> The 1PPS is directly managed by the ntp daemon itself.
> It can be, but that is not the best way.
> The best way is to have gpsd do it.

Ok, this doesn't contradict the information I found, but is
slightly different.
Originally I run a programm called "rpi_gpio_ntp". Maybe you know it.
It reads the GPIO pin and writes to shared memory.
I read this is not an optimum as this task runs in user space ( as
it is the same with "gpsd" ) and generated an additional jitter.
It's better NTP reads directly the KPPS.
This is what I have seen. Maybe not true.


> If you are in fact telling ntpd to open /dev/pps0 then that perfectly
> explains why gpsd can not open /dev/pps0.

Partly not. As I said, even if "ntpd" is NOT running I have this error.


> Read the gpsd time service howto for the preferred configuration.

I found your page weeks ago. Thanks, very useful.
And I run the NTP configuration you mentioned in this doc.
But - as I said - I used "rpi_gpio_ntp". Very obviously I didn't have
success with having this error.

Many thanks to be so patient with me but I am sure our dialogue will
help others too.


Kind regards
Hans

--


Am 05.08.2015 00:35, schrieb Gary E. Miller:
> Yo hans!
>
> On Wed, 05 Aug 2015 00:01:33 +0200
> hans mayer <address@hidden> wrote:
>
> > Many thanks again for your support but I am not a step further.
> > I compiled the kernel with pps debug in the hope to see more.
> >
> >   > You probably do not have KPPS in you kernel
> >
> > I have. Here are the modules
> > bananapi:root> lsmod | grep pps
> > pps_ldisc               2310  0
> > pps_gpio                3357  0
> > pps_core               10107  2 pps_ldisc,pps_gpio
>
> That looks good.
>
> > Here some syslogs:
> > ( as of the fact I switched on the kernel pps debugging )
> > Aug  4 23:38:47 bananapi kernel: [ 1011.465714] pps pps0: PPS event
> > at 1438724326.994917747
> > Aug  4 23:38:47 bananapi kernel: [ 1011.469126] pps pps0: capture
> > assert seq #1001
>
> Also good.
>
> But you fail to mention how you enabled /dev/pps0.  Maybe you did
> earlier, but my memory is short.
>
> > and NTP also working fine with PPS/ATOM support 127.127.22.0
>
> Using what config?
>
> > There is till the issue that original version 3.6 doesn't generate
> > syslog error messages but self compiled version 3.15 does
>
> Which could be good, or bad...
>
> > These are the messages I have:
> > Aug  4 23:44:44 bananapi gpsd[2580]: gpsd:ERROR: KPPS:/dev/ttyS2
> > kernel PPS failed Connection timed out
> >
> > And it's not a kernal message, it comes from gpsd.
>
> Yes, obviously.
>
> > Why does gpsd try kernel PPS ?
>
> Because it provids more accurate time.
>
> > And how ?
>
> By opening /dev/pps0
>
> > Also /dev/ttyS2 is confusing me.
> > ttyS2 is the interface where the GPS module sends the serial data.
> > The 1PPS is on GPIO pin 18 - a different pin.
>
> And your confusion is?
>
> > I found in the documentation "build.txt" the following
> > pps=yes is the default
> > pps=no.  You'll lose support for updating the clock from PPS pulses.
>
> Since gpsd is outputting the KPPS error you obviously built with pps=yes.
>
> Which is what you want.
>
> > What does it mean ?
>
> It means you get zero PPS zupport.
>
> > Which clock is not updated ?
>
> Whichever clock you configured: SHM, or chronyd socket.
>
> >   I don't want that gpsd updates any
> > clocks.
>
> That is sort of the hole point of PPS.  But yes, it only does that indirectly
> by way of SHM and/or chronyd socket and then from ntpd or chronyd to your
> system clock.
>
> > gpsd has only one function to read the data from the gps
> > module.
>
> Yes, and the PPS also is data from the PPS.
>
> > The 1PPS is directly managed by the ntp daemon itself.
>
> It can be, but that is not the best way.  The best way is to have gpsd
> do it.
>
> If you are in fact telling ntpd to open /dev/pps0 then that perfectly
> explains why gpsd can not open /dev/pps0.  Read the gpsd time service
> howto for the preferred configuration.
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>         address@hidden  Tel:+1(541)382-8588