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

[Mick Durkin]

Hi Gary,

Thanks for the reply.

> 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

I did read the document on the project website, hence my remarks
about the "missing" old options. I came with these questions after
reading that document. Evidently, I did not grasp the full story.

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

OK, maybe... What I was trying to convey was that the hardware
was wired up correctly and could be configured to read the GPS
and PPS signals as we were able to get good output from cgps and
chrony. My thinking was that if we subsequently did not get good
results out of gpsd (and, eventually) NTPsec, it would be due to some
issue caused by how we configured and compiled them.

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

This is a dedicated timeserver running permanently to deliver time to the
local network. I was aware of the differing aims of NTPsec and chrony.
I run NTPsec on my own network, so I prefer using someting I understand.

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

Ok, yeah. You got me. Sloppy choice of word 8^)

> 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

Good to get the accurate info about the options. I will go ahead and
start building with a straight out of the box git clone.

Great support, as usual.

BR

Mick