gps-receiver (device class)¶
USB GNSS receivers — position for APRS and grid squares, and time for FT8
USB GNSS receivers as a family rather than as products: a dongle, a puck, a module on a breakout board, or a handheld with a data cable. Nearly all of them present as a USB serial port, either natively or through a bridge chip, which is why they are one class and not eleven devices.
Devices in this class¶
None catalogued yet.
Shared setup¶
Install gpsd, gpsd-clients and gpsd-tools, join dialout, then log out and back in — group membership does not apply to a session already open. Attach the receiver and run cgps; a fix takes a minute or two from cold with a clear view of the sky. There is no udev rule to write: gpsd ships one and it already gives you /dev/gps0.
Power control¶
This device can be parked and woken. Method: usb_deauthorize.
gpsd handles hot-unplug itself — Debian ships USBAUTO="true" in /etc/default/gpsd, confirmed live on Parrot 7.3 — so nothing needs quieting before the port goes down. Measured on the field laptop with a u-blox 9 (bench-verification-5430.md, session 10): on park, gpsdctl@ttyACM0 removed the device from a running gpsd within a second and /dev/ttyACM0 was gone; on wake, the kernel re-created ttyACM0 and /dev/gps0 and gpsdctl handed it back to gpsd within a second, with no action from the operator. A 3D fix was back by 74 s after the wake (the first poll to see one; polled every 15 s or so). The receiver keeps its USB entry while parked, so lsusb still lists it. Parking it also turns GPS time off (D-058): ntpd stops hearing the receiver and follows the network, or holds over, until it is woken (inferred from ntpd's reachability rules, not yet watched on the bench). See docs/guides/gps-time.md.
See device power control for what parking does to a machine, how to inspect it and how to reverse it.
After suspend¶
hammunition hardware apply installs a resume step for this device: gpsd_reopen.
Measured on the field laptop (issue #177): a USB receiver is not re-enumerated across a suspend, so nothing removes it from gpsd and adds it back, and a client watching across the suspend (cgps, xgps, the map tether, or gpsd running with -n for GPS time) can find gpsd holding a tty that has gone quiet: no fix comes back. hammunition hardware apply installs a resume step for that. After every suspend or hibernation, hammunition-gps-resume.service runs gpsdctl remove and gpsdctl add for each /dev/gpsN, and systemctl try-restart gpsd.service if gpsd then reports no device; it makes no check that data flows, so a receiver gpsd still lists but that stays silent is not restarted automatically. It does nothing when no /dev/gpsN exists, so a parked receiver stays parked, and it never parks or wakes anything: if a fix still does not come back, sudo systemctl restart gpsd.socket gpsd, and then hammunition hardware park gps-receiver and hammunition hardware wake gps-receiver, are the operator's steps, by hand. Whether the first step alone brings the fix back after a real suspend is what the bench steps on issue #177 measure; until they are run it is the design the measurement points to, not a measured recovery.
See after suspend for what the step installs, how to inspect it and how to reverse it.