Re: How to use PPS device other than /dev/pps0

[Adam Nielsen]

> > On my Raspberry Pi, the kernel PPS driver picks up /dev/ttyAMA0 as a
> > serial port  
> 
> Uh, no.  The Pi PPS driver knows nothing of ttyAMA0.  You have to tell it
> which gpio pin to use.  Often 18 or 4.

Yes I have set the Pi PPS driver to GPIO 18 (the default), however I am
also seeing the UART get added as a potential PPS source as well.  My
dmesg says:

[   31.778008] pps_core: LinuxPPS API ver. 1 registered
[   31.780037] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo 
Giometti <giometti@linux.it>
[   31.912900] pps_ldisc: PPS line discipline registered
[   31.949866] pps pps0: new PPS source ttyAMA0
[   31.952067] pps pps0: source "/dev/ttyAMA0" added
[   32.483064] pps pps1: new PPS source pps@12.-1
[   32.485328] pps pps1: Registered IRQ 160 as PPS source

Here you can see the Pi GPIO source ending up as pps1, where the
ttyAMA0 got registered as pps0.  Since I am not using ttyAMA0's
limited control signals (I believe it only supports RTS and CTS on the
Pi), pps0 will never provide any information.

> So you are using ttyAMA0 and another serial port?  The Pi only has
> one serial port.

The Pi has two UARTs (six for a Pi 4) however I am only using ttyAMA0
for GPS.  The second UART (normally used to communicate with the
internal Bluetooth controller since the Pi 3) is disabled by default on
the Pi 1 I am using.  I don't have any other serial port devices
available.

> >  But sometimes when I boot,  
> 
> Well, that is long before gpsd enters the picture.  A huge number
> of ways for Pi boot to fail.

The boot isn't failing, I just mean that the assignments between
/dev/pps0 and /dev/pps1 change unpredictably.  Yes it is long before
gpsd starts, but it means when gpsd does start, pps0 and pps1 could be
swapped from one boot to the next.

> > the GPIO one registers first as
> > /dev/pps0 and ttyAMA0 gets /dev/pps1 instead, so it's unpredictable.  
> 
> Which makes no sense.

Please see the dmesg output above, hopefully that explains better what
I am seeing.

> Please provide your /boot/config.txt, /boot cmdline.txt, and your
> gpsd command line.

The gpsd command line is "gpsd -n /dev/ttyAMA0 /dev/pps-gps".  I'll
omit most of config.txt and cmdline.txt as it's mostly the upstream
default aside from some root-over-NFS options, however the config.txt
part I am using for setting the PPS device is:

  enable_uart=1
  uart_2ndstage=0
  dtoverlay=pps-gpio,gpiopin=18

However this part works fine.

> > To solve this I set up a udev rule to symlink the correct one to
> > /dev/pps-gps, and then I launched gpsd with the parameters
> > "/dev/ttyAMA0 /dev/pps-gps".  
> 
> A pain, but if it works, why fix it?

It wasn't working, and this was part of my attempt to get the inactive
PPS device to disappear from ntpd's list.

> > Everything looks fine and gpsmon is giving me PPS offset messages once
> > a second.  
> 
> gpsmon is not a tool to debug PPS.  RTFM.

I also used ppstest and that's how I found /dev/pps0 was not returning
any output but /dev/pps1 was.  However at this point I wasn't trying to
debug PPS, just confirm that gpsd was seeing a PPS signal which gpsmon
told me it was.

At this point I was under the assumption that gpsd handles all the PPS
activity as well, however I have since begun to question this
assumption given what I have discovered below.

> > However when I link this up to ntpd via the SHM driver, it doesn't get
> > any PPS data.  
> 
> The propero tool, as root, is: ntpshmmon.

Thanks for this.  This tool gives me output like this:

#      Name  Seen@                 Clock                 Real                 L 
Prc
sample NTP2  1641342661.001140443  1641342661.000004453  1641342661.000000000 0 
-20
sample NTP0  1641342661.128263341  1641342661.126983352  1641342661.000397777 0 
-20
sample NTP2  1641342662.001053777  1641342662.000006786  1641342662.000000000 0 
-20
sample NTP0  1641342662.119693749  1641342662.118331761  1641342662.000398116 0 
-20

Which seems to confirm that it's only the .0 and .2 device returning
data, the .1 device attached to /dev/pps0 is not returning anything, as
expected.

> > Further investigation reveals that the SHM driver is
> > using both /dev/pps0 and /dev/pps1:
> > 
> > 127.127.28.0 - GPS
> > 127.127.28.1 - /dev/pps0
> > 127.127.28.2 - /dev/pps1  
> 
> Well, you set it up that way.  Send your ntp.conf and I'll show you.
> OTOH, that should work just fine.

It does work, but the problem is when the PPS signal drops out, ntpd
falls back to the GPS time which is at least 100 ms out and has a lot
of jitter.  So once the PPS signal goes away, ntpd starts pulling the
local clock towards the less precise time coming in over the UART and I
want to prevent that from happening.  When the PPS signal goes away, I
want ntpd to completely ignore any GPS time sources.

My ntpd.conf is this:

  # GPS Serial data reference
  server 127.127.28.0 minpoll 4 maxpoll 4
  fudge 127.127.28.0 time1 0.0 refid GPS minjitter 1

  # Unused PPS reference, sometimes GPS (/dev/pps0)
  server 127.127.28.1 minpoll 4 maxpoll 4 prefer
  fudge 127.127.28.1 refid PPS

  # GPS PPS reference, sometimes unused (/dev/pps1)
  server 127.127.28.2 minpoll 4 maxpoll 4 prefer
  fudge 127.127.28.2 refid PPS1

  # minclock 2: Set host time when 2 or more clocks are available (default 3)
  # minsane 2: Require at least two clocks (GPS+PPS) in order to consider time 
valid
  # mindist 1: Allow larger variations because of the GPS serial data being up 
to a second out from the PPS data.
  tos minclock 2 minsane 2 mindist 1

The issues I am trying to solve are:

 1. I want to add some remote servers to set the local host time before
    the GPS signal has locked.

 2. With the PPS data present, I want to sync to that in preference to
    anything else.

 3. When the PPS data goes away, I don't want it to sync to the GPS
    time coming in over the UART, as it's off by at least 100 ms.

I haven't yet figured out a way of having ntpd ignore the GPS time when
the PPS signal goes way, *and* still sync to a remote server.  (Can do
one or the other but not both.)

> > The problem is that sometimes when I boot I should use /dev/pps0 and
> > NTP has to use the .1 address, but other times when I boot I need to
> > use /dev/pps1 and NTP has to be changed to the .2 address to work.  
> 
> If you have ntpd reading both, it will pick the good one automagically.

It does pick the right PPS device when both are listed, but the problem
is if neither is available it has a tendency to sync to the GPS UART
time, which is off by ~120 ms.

Using the "tos" option seems to work - it tells ntpd to ignore the GPS
UART time if both PPS sources are unavailable.

The problem is if I try to add a remote server, I can't see a way to
then ignore the GPS UART time if the PPS signal is missing.  Having an
extra always-broken PPS source in the list complicates things.

> > I
> > don't want to leave both .1 and .2 enabled as then I always have a
> > failed device in the list, which causes other issues with ntpd over
> > time.  
> 
> What other device could you possibly have on a PI that has one half-assed
> serial port.

See the dmesg output above.

> > It would seem that I need to be able to tell gpsd to only use
> > /dev/pps-gps and to not open any other /dev/pps* devices.  
> 
> But, you already did that above.

Well I'm thoroughly confused now.  I was going to post the output of
fuser here to demonstrate that gpsd is opening all PPS devices, but now
I see it only opening the single device I specified on the command
line, which suggests gpsd is behaving correctly after all.

Perhaps the issue is actually with the NTP SHM driver?  Maybe it opens
all the PPS devices, bypassing gpsd entirely?  I was under the
assumption the NTP SHM driver only spoke to gpsd but that looks like it
may not be the case.

> > This way I
> > should be able to always use the .1 address for ntpd regardless of
> > which actual device is in use, as gpsd would only ever be using one
> > of the two PPS devices.  
> 
> Don't worry about that.  Such a common problem tht gpsd and ntpd
> handle it fine.

ntpd doesn't seem to.  I already tried it and without the "tos" option
in ntp.conf, ntpd likes to sync against the GPS UART source and it makes
the local time inaccurate due to the delay sending the serial data
across the UART.

There is also a driver ID 46 <http://doc.ntp.org/archives/drivers/driver46/>
that's supposed to talk directly to gpsd and looks like it might solve
my problem (by only providing a single source device for both GPS time
+ PPS) however I have been unable to get that to work.

I have also discovered that this may be the source of the PPS problem.
The NTP driver 46 says it requires a device name of the form /dev/gpsX
even though it does not use the device.  The only way I could get it to
start returning time values from gpsd was to make gpsd use a /dev/gpsX
device as well:

 1. Symlink /dev/ttyAMA0 to /dev/gps0
 2. Run "gpsd -n /dev/gps0 /dev/pps-gps"
 3. Use 127.127.46.0 in ntp.conf, with the .0 meaning /dev/gps0

If gpsd was not using the /dev/gps0 device, no values were being
returned to ntpd.

However I now see when I run gpsd and point it to /dev/gps0, that's
when it somehow triggers the kernel to add a PPS source for
/dev/ttyAMA0:

  # gpsd -n /dev/gps0 /dev/pps-gps

  # dmesg | grep pps
  pps pps0: new PPS source ttyAMA0
  pps pps0: source "/dev/ttyAMA0" added

  # killall gpsd

  # dmesg | grep pps
  pps pps0: removed

So gpsd seems to behave differently when given a /dev/gpsX name as
opposed to /dev/ttyX, even though the underlying device is the same.

At any rate it looks like this is actually the source of the PPS
confusion, and I should not pass /dev/gps0 as a parameter to gpsd.
However now I am wondering what the purpose of NTP driver ID 46 is for,
if you can't use it to connect to gpsd properly.

> > How can I tell gpsd to only use the PPS device I specify and not to
> > open any other PPS devices?  
> 
> In what I THINK is your config, just disable the MAGIC_HAT build
> option.  Or figure out where the second pps is common from and fix that.
> I suspwect a bad udev rule.

So looks like the issue is the /dev/gps0 symlink being passed to gpsd,
and changing that back to /dev/ttyAMA0 removes the unwanted PPS device.
However I would appreciate any suggestions you have for how to get ntpd
to communicate with gpsd, as driver ID 28/SHM seems to make it
difficult to ignore the GPS source when the PPS signal goes away, and
driver ID 46/GPSD_JSON doesn't seem to return useful time values and
causes an extra PPS source to appear.

Cheers,
Adam.