Skip to content

gpsd

GPS service daemon — one process owns the receiver, everything else asks it

What it does

Runs as a daemon, opens a GPS or GNSS receiver, and serves the position, time and satellite data to any number of clients over a local socket on port 2947. Applications talk to gpsd rather than to the receiver. This package also carries ubxtool, gpsctl, ppscheck and ntpshmmon — verified by listing its contents on Debian 13, because the name suggests they would be in gpsd-clients and they are not.

Why you would want it

A serial receiver can only be opened by one program at a time, and a ham station routinely wants position and time in several places at once — APRS beaconing, grid-square lookup, satellite prediction, and a disciplined clock for FT8 and JS8, where the whole protocol depends on the station clock being right. gpsd is what lets all of them read one receiver. It is also the thing chrony takes a PPS reference from.

Before it will work

A receiver the machine can see. Most USB GNSS units are USB-serial devices, so the identifiers and permissions come from the gps-receiver hardware class. Nothing needs configuring by hand for a hotplugged USB receiver — gpsd's own udev rule starts it on the device.

How it installs

  • apt: gpsd, pps-tools
  • pps-tools carries ppstest and ppsctl, which hammunition time measure --pps runs (issue #319). ppstest /dev/pps0 prints one line per pulse, source 0 - assert <seconds>.<nanoseconds>, sequence: N - clear ..., about once a second when the device gets real pulses, and time_pps_fetch() error -1 (Connection timed out) when it gets none; it needs root on most machines. Not every receiver has a PPS device: one on a USB CDC-ACM line (/sys/class/pps naming it for the ttyACM device) is not a wired time-pulse pin, and its pulses are absent or jitter by milliseconds. gpsd is the owner because both GPS time routes read it: D-058's ntpsec lines and the chrony unit (D-072) depend on it. apt-cache policy on 2026-10-04, Parrot 7.3: pps-tools 1.0.2-2 has a candidate; the other six targets were not swept for it, and apt reports the truth at plan time.

Known problems

gpsd's udev rule does not merely name the device, it starts gpsd on it — ENV{SYSTEMD_WANTS}="gpsdctl@%k.service". That is correct for a GPS and hostile for anything else that happens to share an identifier, which is why Debian ships the rule with five entries commented out and the note "rule disabled in Debian as it matches too many other devices". Two of those five are the FTDI FT232 and the Silicon Labs CP210x — the chips in most rig control cables. If yours is on the list that is still enabled, gpsd will open it and your logging software will find the port busy. The gps-receiver class documents which identifiers those are.

Keeping it current

  • probe: apt policy
  • strategy: apt_upgrade

Where to get help with the software itself

gpsd-users mailing list

Source: catalog/packages/gpsd.yaml