Re: Help needed to configure and compile gpsd to run on a Raspberry Pi 4 and NOT use systemd

[Gary E. Miller]

Yo Mick!

On Tue, 12 Nov 2024 21:28:31 +0000
Mick Durkin <mickdurkinuk@gmail.com> wrote:

> My son wanted to have a timeserver on his internal network, so he
> decided to go down the path of using a ublox type GPS module with a
> serial interface and a PPS signal driving gpsd on a Raspberry Pi 4.

Very common thing to do.  Did you read any of our howto's for that?

> He installed the latest version of Raspbian and followed the
> instructions in one of many YouTube tutorials
> (https://youtu.be/7aTZ66ZL6Dk?si=4t6ErNw4Stdc6W4I) and successfully
> got Chrony to supply time for him. All the tutorials online seem to go
> down the same road and use the dreaded systemd.

Ours do not.

> However, this means
> electrically things are connected correctly and the Pi's configuration
> (e.g. activating the UART and setting up the PPS pin) is good.

That might be stretching the point a bit...

> He then contacted me and told me what he had been able to do. As a
> long time gpsd user (I have been tinkering with gpsd since about 2005,
> when I wrote myself a driver for my Jupiter-T module and have made
> minor contributions to the codebase over the years), I was not happy
> that he was running gpsd under systemd. I pointed him to Gary's many
> posts exhorting users not to use systemd with gpsd, but rather to
> install cleanly from the source.

Of course I approve of that.

> I am quite happy going down this path, so I persuaded him that this is
> the way to go. I also said we might install NTPsec (from source)
> rather than Chrony.

Depends on the use case.  Chrony is better for laptops and systems that
boot frequently.  NTPec is better as a dedicated chimer that you just
leave running on the network.

> Having never compiled gpsd for the Raspberry Pi, I dug into the
> SConscript file to look at the "boolopts" table to see if there was
> anything relevant.

There is not.  The defaults are fine.

> In "Other daemon options" "systemd" was set to "systemd". I wonder if
> this should be changed to "False" if we don't want any systemd
> "pollution"?

Nah.  It is just a few config files.

> In "Build control" the "magic_hat" parameter had me mystified.

Yeah, I wish that had never happened.  It is automagivally set when
needed, whihc is when runnong on a raspberry pi.  For some reason
most distros force it on for all builds.

> As we
> are using simple serial data + PPS into the Pi's UART port, we don't
> have a hat.

Twp things: 

1) RasPi's do not have UARTs That is: Not RTS, CTS, DSR, DCD, etc..
Just dumb serial ports (Tx/RX)

2) "Hat" is an over reach by the author of that.  His intent was to
automgaically use the GPIO pin on the RasPi.

All it does is allow you to say:
    gpsd -n /dev/ttyAMA0

Instead of:
    gpsd -n /dev/tthAMA0 /dev/ttypps0

> Should this be set to "False"?

No.  Just use all the defaults.

> Also, I think the "timeservice" flag should be changed to "True".

"timeservice" builds a minimal gpsd, don't do that.

> The
> instructions at
> https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html say "If you
> do not use timeservice=yes, then make sure the build is with pps=yes
> and ntpshm=yes (the defaults)."

As it says, those are the defaults.  Just leave the options alone.

> However, there does not seem to be
> either a "pps" parameter or an "ntpshm" parameter in the latest code.
> It might be the online document is out of date and I should simply set
> "timeservice" to be "True"?

Yes, those have been removed, and the howto has not been updated.  The
options had no useful purpose, and just ended up in peole making bad
choices.

> I would be grateful if members of the list could clarify these points
> for me.

Clearer?  All you need to know: just go with the defaults.  In 2003
it may have still mattered to save a few kB of binary, but not in 2024.

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