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

[Gary E. Miller]

Yo Adam!

On Wed, 5 Jan 2022 12:30:43 +1000
Adam Nielsen via <gpsd-users@nongnu.org> wrote:

> > > 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),

Facts not in evidence.

I also run a GPS HAT on a Pi and see nothing like you do.

> however I
> am also seeing the UART get added as a potential PPS source as well.

There is no PPS associated with /dev/ttyAMA0.  You are confusing this
with the magic hat option, which merely 

> 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

I need the whole log.  I need the stuff before that too.

> Here you can see the Pi GPIO source ending up as pps1, where the
> ttyAMA0 got registered as pps0.

How do we know which is from gpio 18?  gpsd never createa a /dev/pps for
/dev/ttyAMA0.  Can you confirm you have the magiv hat option?

>  Since I am not using ttyAMA0's
> limited control signals (I believe it only supports RTS and CTS on the
> Pi),

No, it does not.

> pps0 will never provide any information.

And yet, it does for me.  Since the gpio PPS is tarted at boot time, it
should always be the gpio PPS.  Unless udev or systemd(umb) is renaming
things.  Which it is wont to do.


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

Uh, no.

https://www.teachmemicro.com/raspberry-pi-serial-uart-tutorial/

    "Technically, the Raspberry Pi has two UARTs: PL011 UART and mini
    UART. However, you only have one pair of TXD and RXD pins to work
    with."

> however I am only using ttyAMA0
> for GPS.

The only thing you can use.

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

Double check that.  As the URL shows above, they SHARE the same TX/RX
pins.  This is a common misunderstanding.

> I don't have any other serial port devices
> available.

OK.  Many use USB to serial for GPS.

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

Facts not in evidence.  Somthing is failing, and I suspect it is
in your config files, not provided as asked.

> I just mean that the assignments between
> /dev/pps0 and /dev/pps1 change unpredictably.

Which is bonkers.  The gpio_pps driver does not rename things.  OTOH,
udev and systemd(umber) do.


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

Always stop at the First Failure.  Until you fix you pps0 and pps1, there
is no point having gpsd installed.  There is nothing gpsd can  do to
unbreak a system.

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

No, because you cut it down way too much.

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

Once again, you cut to much.  The upstream  defaults will break gpio_pps.

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

And where did you disable the BT that shares the same port?

> However this part works fine.

We'll have to agree to disagree.

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

Now you are WAY past the first failure.  No point starting ntpd until
ntpshmmon says gpsd is putting out PPS.  No point starting gpsd
until your only have one /dev/ppsX before gpsd starts.

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

So, time to go back and do that debugging.  Start by removing any
and all udev rules for pps.  They are never, ever, needed.  More
over complexity from systemd(umbest).

> At this point I was under the assumption that gpsd handles all the PPS
> activity as well,

Depends on how you define "handles".  In normal operation, yes, only gpsd
should touch the pps.

> however I have since begun to question this
> assumption given what I have discovered below.

Don't.

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

That sure looks good.  Serial time on NTP0, and PPS on NTP2.

If you make that stable, configure ntp.conf to use that, and you are
done.

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

Uh?  Wait?  NOTHING but gpsd should be touching pps0 or pps1!

> > > 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 pointlessly tries to read SHM0

And you should consider the new syntax that does not do those crazy
things with fake IPv4 addresses.


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

Yes, that is normal for a misconfigured ntp.conf.  Did you read the
doc?

>  So once the PPS signal goes away, ntpd starts pulling the
> local clock towards the less precise time coming in over the UART and

Yup.  So do not do that!

> I want to prevent that from happening.  When the PPS signal goes
> away, I want ntpd to completely ignore any GPS time sources.

Of course.  But totally unrelated to the issue you started with: 
multiple /dev/ppsX.

> 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

Several things wrong here. 

Your ntp.conf should be ordered, best sources at the top, worst at the
bottom.  So this should be last, not first.

You can add a high fudge, so ntpd will select it only as a last resort.
Or, better yet, add "noselect" so it is displayed, but never used.

The maxpoll and minpoll are WAY too high.

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

If that is never active, why have it at all?

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

This is your est source, t should be at the TOP.

> tos minclock 2 minsane 2 mindist 1

Don't do that!  Add more peers!

> The issues I am trying to solve are:

Which are now way, way off topic, and the people that know this stuff
never got this far because they are not interested in debugging Pi's,
only in debugging ntp.conf.  But they are long gone.

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

Now I know you did not read any of the doc.

    pool us.pool.ntp.org iburst

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

The "prefer" does that, when appropriate.

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

See above.

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

See above.

> > If you have ntpd reading both, it will pick the good one
> > automagically.  
> 
> It does pick the right PPS device when both are listed,

Always?  That is not what you said earlier.

And we keep jumping topics here....

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

See above.

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

For some corruption of "work".  See above.

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

See above.

>  Having an
> extra always-broken PPS source in the list complicates things.

So remove it!  Nothing made it magically appear in your ntp.conf.

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

I see no dmesg.

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

Good grief.

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

Now you are lost in the weeds.  restart from the top.  Fix the obvious
bugs in your config so far.  Then reassess.

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

See above.  All explained already.

> I already tried it and without the "tos" option
> in ntp.conf,

Don't use tos!

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

Uh, oh.  You just overloaded my loop counter.  Abort.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgplRiEoH84nK.pgp
Description: OpenPGP digital signature