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:
> >> 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:
>
> That "prefer" is part of the config file.

True, but it doesn't "tell it which pps goes with which serial port".

> > 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.:
>
> It's some combination of dtoverlay in /boot/cmdline.txt and the kernel
> modules.  dtoverlay takes a parameter for the pin number.  I suspect that
> gets passed to the module.  I don't know if/how it works if you want multiple
> pins.

Yeah, I know the general idea, but at some point I'll have to figure it
out in more detail.

On Mon, 25 Apr 2016, Hal Murray wrote:

> I think the fix will require something like a flag on the command line that
> says the next parameter is the PPS for the previous TTY.  Maybe:
>   gpsd /dev/ttyX0 --pps /dev/pps0

That approach is incompatible with getopt(), which processes all options
and option arguments in one pass, stripping those arguments out, and then
leaves everything else for a separate pass.  Information about the
relative placement of option and non-option arguments is destroyed.

That's why I suggested pairing the two as a *single* argument.
Adnmittedly, the colon I suggested was a poor choice for a delimiter since
it's needed by the URI syntax, but another character could be chosen.


I see there were some changes made with the intent of making the PPS
discovery more automatic in the specific case of RPi/HAT, but that seems
unwise for a few reasons:

1) Adding code whose sole purpose is to obviate a command-line argument in
the case of one specific peripheral on one specific platform running one
specific OS hardly seems justifiable.

2) Assuming that any platform using "/dev/ttyAMA0" as a serial port is a
Rasberry Pi is fragile.

3) Assuming that if "/dev/pps0" exists on a Raspberry Pi, then it must be
the right PPS source is especially fragile.  Suppose a setup were like the
BBB/Yantrr setup, where /dev/pps0 is a fake PPS source and /dev/pps1 is
the real PPS source.  This would autoconfigure completely wrong timing.
It wouldn't necessarily break NTP if NTP were configured to use the right
PPS source, but if NTP were configured to use SHM(1) it would break NTP as
well.


I don't believe there is *any* way to automatically determine the
serial/PPS pairing in the general case, or even for all Linux on Raspberry
Pi cases.  Thus, having a way to specify it manually would not only be
more generally useful, but also wouldn't risk getting it completely wrong
in some cases that it thinks it understands but doesn't.

Fred Wright