What needs adding
docs/user-guide/gps.md currently states:
Signal K connects to gpsd automatically and makes position data available through its API. No additional configuration is needed.
On devices provisioned before halos-org/halos-marine-containers#222 that is not true, and the page gives a reader no way to find out why. Those devices need a manual repair that is not documented anywhere.
The problem, for the docs text
gpsd does not send one NMEA sentence per network write — it sends a whole reporting cycle (ZDA, GGA, RMC, GSA, GSV…) in a single write. Signal K's NMEA parser reads one sentence at a time, so unless a splitter sits between them it receives the burst as one malformed sentence and discards all of it. The connection looks healthy and produces no position.
The baked Signal K connection was missing that splitter. halos-org/halos-marine-containers#222 fixed it by letting Signal K assemble the connection itself, but default-data/ is only copied when the file is absent, so the fix reaches new installs only. Any device already carrying a settings.json keeps the broken connection after upgrading, while apt reports success.
Symptom a user would recognise
gpspipe -w on the device shows a valid fix ("mode": 3, latitude and longitude present), so the GPS hardware and gpsd are fine.- Signal K shows no position:
navigation.position is absent from the API, and the gpsd connection in the admin UI shows activity but produces no data.
- Occasionally
navigation.datetime appears on its own — a ZDA sentence that happened to land alone in a write.
The repair
Preferred, and no shell needed: in the Signal K admin UI, Server → Connections, delete the gpsd connection and create a new one — Data Type NMEA0183, source GPSD, host localhost, port 2947. The server assembles the pipeline correctly, including the splitter. This produces exactly the configuration #222 now ships.
The equivalent by hand, for anyone who prefers it, is to replace the gpsd entry in
/var/lib/container-apps/marine-signalk-server-container/data/data/settings.json
with the single providers/simple element from apps/signalk-server/default-data/data/settings.json in halos-marine-containers, then restart the app. Worth stating explicitly that the file is edited on the host, not inside the container, and that Signal K must be restarted afterwards.
Second, smaller correction on the same page
The page says u-blox reconfiguration "adds a few seconds to gpsd startup". Since halos-org/halos-ublox-config#5, detection listens passively at each candidate rate rather than probing, and measured runs on a HALPI2 take about 11 s in the normal case and up to about 14 s when a configured device produces nothing. "A few seconds" now understates it enough to make a user think something is wrong.
Related
What needs adding
docs/user-guide/gps.mdcurrently states:On devices provisioned before halos-org/halos-marine-containers#222 that is not true, and the page gives a reader no way to find out why. Those devices need a manual repair that is not documented anywhere.
The problem, for the docs text
gpsd does not send one NMEA sentence per network write — it sends a whole reporting cycle (ZDA, GGA, RMC, GSA, GSV…) in a single write. Signal K's NMEA parser reads one sentence at a time, so unless a splitter sits between them it receives the burst as one malformed sentence and discards all of it. The connection looks healthy and produces no position.
The baked Signal K connection was missing that splitter. halos-org/halos-marine-containers#222 fixed it by letting Signal K assemble the connection itself, but
default-data/is only copied when the file is absent, so the fix reaches new installs only. Any device already carrying asettings.jsonkeeps the broken connection after upgrading, whileaptreports success.Symptom a user would recognise
gpspipe -won the device shows a valid fix ("mode": 3, latitude and longitude present), so the GPS hardware and gpsd are fine.navigation.positionis absent from the API, and the gpsd connection in the admin UI shows activity but produces no data.navigation.datetimeappears on its own — a ZDA sentence that happened to land alone in a write.The repair
Preferred, and no shell needed: in the Signal K admin UI, Server → Connections, delete the
gpsdconnection and create a new one — Data TypeNMEA0183, sourceGPSD, hostlocalhost, port2947. The server assembles the pipeline correctly, including the splitter. This produces exactly the configuration #222 now ships.The equivalent by hand, for anyone who prefers it, is to replace the
gpsdentry inwith the single
providers/simpleelement fromapps/signalk-server/default-data/data/settings.jsonin halos-marine-containers, then restart the app. Worth stating explicitly that the file is edited on the host, not inside the container, and that Signal K must be restarted afterwards.Second, smaller correction on the same page
The page says u-blox reconfiguration "adds a few seconds to gpsd startup". Since halos-org/halos-ublox-config#5, detection listens passively at each candidate rate rather than probing, and measured runs on a HALPI2 take about 11 s in the normal case and up to about 14 s when a configured device produces nothing. "A few seconds" now understates it enough to make a user think something is wrong.
Related