Re: [gpsd-dev] PPS not showing in gpsmon/gpsd on RPi 3

[Fred Wright]

On Sat, 23 Apr 2016, Hal Murray wrote:
> address@hidden said:
> > It's obvious why the TIOCMIWAIT isn't working.  What's unobvious is why KPPS
> > isn't.  The ppstest result seems to tell us that the RFC2783 interface is
> > up.  My conclusion is that the GPSD code is failing to use it correctly
> > because of something specific to Pi3/Jessie.

Not just Pi3/Jessie.  It deosn't work on BBB/Wheezy, either.

> It's not specific to the 3 or Jessie part of the setup.  The critical idea is
> that GPIO#<x> isn't linked to /dev/tty<y> in any way.

I think that may matter, but not necessarily for the reason you think.
See below.

> ppstest works because you tell it which /dev/pps<x> to use.  ntpd works
> because you have to tell it which pps goes with which serial port with config
> files and links in the file system.

Actually, not AFAICT.  NTPd works by having you apply the "prefer" keyword
to the corresponding coarse-time peer, which is a horribly disgusting
repurposing of "prefer".  It has two issues:

1) If you want to use some other coarse-time source (e.g. an NTP server
that doesn't have all-over-the-map TOFF values), then you lose the
validation of the PPS signal that comes from tying it to its serial GPS
source.

2) It doesn't work well at all for multiple independent PPS-equipped GPS
sources.

However, it does manage to work well enough in common cases, even when
GPSD refuses to use the PPS.

> We could potentially "fix" things if an available GPIO pin is wired
> within the chip to the right modem control signal on that serial port.
> I don't plan to spend any time on that.

Aargh, no.  Rewiring the hardware to get around software bugs?  Yecch!

On Sat, 23 Apr 2016, Gary E. Miller wrote:
> On Sat, 23 Apr 2016 17:46:02 +0100
> Oliver Jowett <address@hidden> wrote:
>
> > IIRC I had some problems with the timing of when the PPS thread was
> > started; in some cases it would happen after root had been dropped. I
> > think there was a race between the pps thread opening the PPS device
> > and the main thread dropping root.
>
> Yeah, when gpsd was changed to drop root the knock on effects were
> never fully resolved.

That might explain an unrelated problem I've seen, where the initial
startup of GPSD never sends any useful data to the SHM(0) segment, but it
does after a restart.  This is with the V3.6 that' "current" in Wheezy; I
haven't confirmed it in a current version.

On Sat, 23 Apr 2016, Gary E. Miller wrote:
> On Sat, 23 Apr 2016 11:43:47 -0400
> "Eric S. Raymond" <address@hidden> wrote:
>
> > If that's so, why is the startup code referencing a
> > nonexistent /dev/pps1 and throwing permission errors (of all things)
> > on /dev/pps0?
>
> The KPPS error is telling you that is failed to create the /dev/pps1 and
> attach it to /dev/ttyS0.  And that is beccasue there are no RTS/CTS, DTR/DCD
> or RI on /dev/tty1 to create the /dev/pps1 to monitor.
>
> /dev/pps0 is the device that YOU created for the GPIO pin.  Except
> either the permissions are wrong, or gpsd is not openeing it properly before 
> dropping root.
>
> > It's obvious why the TIOCMIWAIT isn't working.  What's unobvious is
> > why KPPS isn't.
>
> Because they both depend on the same thing, having RTS/CTS, DTR/DCD or
> RI on /dev/ttyS0.  You can't monitor signals that do not exist and the
> kernel is smart enough to tell you no when you try. gppsd does not know
> it can not monitor those pins until it tries.

No, the KPPS driver is perfectly capable of monitoring GPIO signals that
have nothing to do with a serial port.  I don't know exactly how it
gets set up, but that much works on the BBB.  E.g.:

address@hidden:~# dmesg|grep pps
[    0.167168] pps_core: LinuxPPS API ver. 1 registered
[    0.167182] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo 
Giometti <address@hidden>
[    0.977606] pps pps0: new PPS source ktimer
[    0.977634] pps pps0: ktimer PPS source registered
[    0.977651] pps_ldisc: PPS line discipline registered
[   46.082757] pps pps1: new PPS source pps.15.-1
[   46.083025] pps pps1: Registered IRQ 155 as PPS source
[   46.417719] pps pps2: new PPS source OMAP-SERIAL4
[   46.417762] pps pps2: source "/dev/ttyO4" added

pps0 is the kernel's internal PPS source.  This is only useful for
testing of the PPS mechanism, not for actual timing.  Unless you're the
sort that thinks that pointing NTPd at localhost as a peer is useful. :-)

pps1 is the "real" PPS from the GPS receiver's GPIO pin.  It works fine,
subject to the "one edge only" limitation.

pps2 is an attempt to get PPS from the GPS receiver's serial port, which
doesn't work because it has no modem control lines.

One can see all this via ppstest (warning - may line-wrap):

address@hidden:~# /usr/src/pps-tools/ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1461463421.333372947, sequence: 2501998 - clear  0.000000000, 
sequence: 0
source 0 - assert 1461463422.337282847, sequence: 2501999 - clear  0.000000000, 
sequence: 0
source 0 - assert 1461463423.341187007, sequence: 2502000 - clear  0.000000000, 
sequence: 0
^C
address@hidden:~# /usr/src/pps-tools/ppstest /dev/pps1
trying PPS source "/dev/pps1"
found PPS source "/dev/pps1"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1461463428.000004338, sequence: 2511328 - clear  0.000000000, 
sequence: 0
source 0 - assert 1461463428.999999985, sequence: 2511329 - clear  0.000000000, 
sequence: 0
source 0 - assert 1461463430.000005964, sequence: 2511330 - clear  0.000000000, 
sequence: 0
^C
address@hidden:~# /usr/src/pps-tools/ppstest /dev/pps2
trying PPS source "/dev/pps2"
found PPS source "/dev/pps2"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
^C

On Sun, 24 Apr 2016, Oliver Jowett wrote:
> On 23 April 2016 at 22:48, Gary E. Miller <address@hidden> wrote:
> > On Sat, 23 Apr 2016 17:46:02 +0100
> > Oliver Jowett <address@hidden> wrote:
> >
> >
> > > Also note that you need _write_ access to the pps device, not just
> > > read.
> >
> > Got a citation for that?
> >
>
> http://git.savannah.gnu.org/cgit/gpsd.git/tree/ppsthread.c#n266
>
> I don't know that it is required, only that gpsd does try to open it
> read-write, which would explain Eric's permission error.

It's definitely not required, even though ppstest does it as well:

address@hidden:~# cd /usr/src/pps-tools/
address@hidden:/usr/src/pps-tools# diff ppstest.c ppstestro.c
18c18
<       ret = open(path, O_RDWR);
---
>       ret = open(path, O_RDONLY);
address@hidden:/usr/src/pps-tools# ./ppstestro /dev/pps1
trying PPS source "/dev/pps1"
found PPS source "/dev/pps1"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1461463742.000008355, sequence: 2511642 - clear  0.000000000, 
sequence: 0
source 0 - assert 1461463743.000005148, sequence: 2511643 - clear  0.000000000, 
sequence: 0
source 0 - assert 1461463743.999997610, sequence: 2511644 - clear  0.000000000, 
sequence: 0
^C

There's no good reason why it should require write access, given that it's
a sharable device (contrary to something posted in the archives).  I've
run four simultaneous copies of ppstest pointed at the same device with no
issues.

I do have a suspicion as to what the problem might be, however.  When I
first encountered this problem, I made a cursory examination of the GPSD
source code, and found what looked like some code that was requiring the
sysfs "path" parameter to match a GPS serial port in order for it to be
considered.  On the BBB at least, that's *only* set up for the PPS device
that's pointed at the nonexistent serial modem control:

address@hidden:~# cat /sys/class/pps/pps0/path

address@hidden:~# cat /sys/class/pps/pps1/path

address@hidden:~# cat /sys/class/pps/pps2/path
/dev/ttyO4

So I suspect that GPSD is perfectly happy to use the useless pps2, but
unwilling to use the perfectly good pps1.

Indeed there's an issue with how PPS sources are paired with their
associated serial sources, and expecting this to come from sysfs is
probably too inflexible.  One possibility that's occurred to me is to
allow one to specify the serial source and the PPS source as a single
argument on the command line (perhaps separated by a colon), so that the
pairing can be stated explicitly.  That wouldn't work for dynamically
attached USB receivers, but using dynamically attached receivers as
trusted time sources probably isn't a good idea, anyway.

Note that it's not necessary to make this work just to get NTPd to use the
PPS source, since it can do that directly (even if GPSD were also using
it), but GPSD seems like a more appropriate place than NTPd to put
knowledge of the idiosyncrasies of various receivers' TOFF behaviors.
GPSD could provide "sanitized" coarse time to NTPd, which would be
especially useful given that NTPd is way too fussy about the offset.

Fred Wright