Skip to content

GPS

GNSS data source. Drives a u-blox receiver over its UART, publishes position and velocity channels on the data context, feeds GPS time samples to chronyd, and advertises a dsource.

Module id: gps. Typical channels: gps.channel.position (GeographicCoordinate), gps.channel.direction (GPSVelocity). See Data Pipeline and Hardware Integration for PPS timing.

Configuration

Config type Component ref Description
gpsapp gps.gpsapp.main GpsAppConfiguration is the singleton gps.gpsapp.main receiver configuration: whether the gps module drives the GNSS receiver, the UART speed it talks to it at, and the navigation rate it programs into it.

Receiver configuration

How the receiver is driven is the gpsapp config on gps.gpsapp.main: whether the module talks to it at all (enabled), the UART speed (baudRate) and the navigation rate (frequency, 0.5 to 25 Hz). The module seeds that config disabled, so a device without one produces no GPS data: no port is opened, no command is sent, and chronyd gets no GPS time samples until it is enabled. A device upgrading from the release that drove the receiver from the --frequency and --baud-rate flags has one written for it once, at the 5 Hz and 115200 baud those flags carried, as long as it has a channel on gps.dsource.gps and no gpsapp config of its own.

On an enabling config the module finds the receiver at whatever speed it currently talks at, switches it to the configured speed, sets the rate, enables NAV-PVT per epoch and NAV-SAT about once a second, and saves that to the receiver's battery-backed RAM. It then measures the NAV-PVT stream and reports the config OK only once the measured rate matches the configured one; until then it is WAIT, and data is not published. A rate the receiver refuses (a NAK on the rate command) is ERROR until another rate is configured. The tables of both status axes are in the gpsapp entry.

A rate change rebuilds every channel on gps.dsource.gps against the new rate before the receiver is touched; a channel that cannot run at it refuses the change, and the receiver stays as it was. Channels are held back at first configuration by a configRef on gps.gpsapp.main, see Consumer binding.

Which device node the receiver hangs off stays a flag: compose binds it into the container, so no config could make another one appear.

Flags

Flag Default Meaning
--gps-device /dev/ttyLP0 Device node of the receiver's UART, as bound into the container
--nmea-sock-path - chronyd SOCK refclock path; when set, every NAV-PVT time is sent as a time sample
--gps-wait-between-reconfig-min 2s First wait between two configuration attempts; doubles per attempt
--gps-wait-between-reconfig-max 60s Cap on that wait
--status-pub-interval 10 Telemetry interval in seconds
--config-pub-interval 0 Config status republish interval in seconds, 0 off

Plus the flags every module has (--nats-url, --nats-key-dir, --id, --log-level, --app-start-counter-file). The former --frequency and --baud-rate flags are gone; both live in gpsapp now, and --baud-rate=0 ("leave the receiver alone") is enabled = false.

NATS endpoints

None declared.

Config, status, and data only.