[Feature Request]: gpsd client support

[sgofferj]

Platform

ESP32, Linux Native

Description

gpsd is the de-facto standard for sharing GPS data in Linux network. Implementing a gpsd client into Meshtastic would provide Wifi-/LAN-connected Meshtastic devices which don't have their own GPS with location and time information. I would also consider that useful for Linux native devices which run meshtasticd but want the GPS data also for other applications on the device.
The protocol is trivial. You open a tcp connection to port 2947 and send ?WATCH={"enable":true,"json":true}. Gpsd will start sending GPS and other data as JSON. ?WATCH={"enable":true,"nmea":true} will get you an NMEA stream.
A detailed protocol description and example code are available here: https://gpsd.gitlab.io/gpsd/client-howto.html

[thebentern]

This sounds very interesting!

[GPSFan]

The package version for gpsd on debian bookworm is 3.22-4.1 from Jan 2021.
3.23 has fixes for u-blox 6 &7 initialization issues and adds M10 support.
3.25.1~dev: is the current work in progress code and has "some" support for ATGM336 receivers.
As these are popular with Meshtastic folks we might have issues using the bookworm standard distribution's package. gpsd is quite flexible in its support for "unsupported" receivers and there could be some workarounds to enable 3.22 to be ok.

https://gpsd.gitlab.io/gpsd/NEWS

As for gpsd on an ESP32, that's an interesting thought.

[jp-bennett]

Yeah, should be relatively easy to make this work. For native, it'd just be a config entry in config.yaml, and a different code path in the GPS.cpp code.

[sgofferj]

As for gpsd on an ESP32, that's an interesting thought.

I meant, as client, of course. E.g. if you have some ESP32-based router node which is anyways connected to your wifi for MQTT.
At least a couple of years ago, having a GPS RX on a "homeserver", feeding gpsd feeding an NTP daemon was a thing as a fairly high precision and internet-independent time source. I would assume, there is some overlap between the "inet independent time source" and "off grid messaging" crowds... But IIRC somebody has ported gpsd to ESP32. Can't find it adhoc but I'm sure I ran across that somewhen.

[GPSFan]

I'd think that for native, we could get rid of TinyGPS++ and just grab the position/heading/speed/time or other data we want right from gpsd, letting gpsd manage the receiver(s), No NMEA decoding needed.
Would this be a goal for Meshtastic V3?

[jp-bennett]

I'd think that for native, we could get rid of TinyGPS++ and just grab the position/heading/speed/time or other data we want right from gpsd, letting gpsd manage the receiver(s), No NMEA decoding needed. Would this be a goal for Meshtastic V3?

Not entirely, no. It's too useful to be able to debug TinyGPS++ on native. But I could see a future where we default to gpsd on native.

[GPSFan]

I see your point.
I have gpsd installed on an arm64 bookworm Rock64, I also have meshtasticd installed there too, I will have a go at running them together and see what I can cobble together. What I really need is to be able to compile native on one or the other, I had less than success installing the Platformio plugin for vs code on my RPi3B+.
Maybe that was a power supply issue too ;>((

[jp-bennett]

I see your point.
I have gpsd installed on an arm64 bookworm Rock64, I also have meshtasticd installed there too, I will have a go at running them together and see what I can cobble together. What I really need is to be able to compile native on one or the other, I had less than success installing the Platformio plugin for vs code on my RPi3B+.
Maybe that was a power supply issue too ;>((

That issue is probably running out of ram. It takes 4gb to run the full vscode backend reliably.

[GPSFan]

Ahh, any chance of cross compiling?

[jp-bennett]

Ahh, any chance of cross compiling?

You can probably get away with running the compile from the command line, using the script in /bin. The pio command can take the -j flag to limit compile threads, if you need it.

[GPSFan]

Well it got everything compiled and failed in the ld phase with a bunch of undefined references in PiWebServer.cpp, This is on my Rodk64, so there is probably a missing library unique to the Pi. I'll repeat this on the Pi now that I know how to set up the venv etc.

[GPSFan]

Got it all compiled linked and it runs on my Pi3b+.
Had to increase the swap space from default of 100MBytes to 500MBytes.
Have the same error -7 from RadioLib when packets come in.

[sgofferj]

Regarding compiling for Arm... Oracle Cloud Services has an extremely generous free tier for Ampere Arm64 instances... I got a lot of stuff on there including a drone.io worker to build containers for Arm64.

[madeofstown]

Have the same error -7 from RadioLib when packets come in.

I get the error -7 quite frequently on Meshtasticd. I also get it a decent amount on a Pico W and got a new RAK node recently that is also logging these errors. What is that all about? My googling has failed me.

[jhollowe]

As a note, you can already use gpsd by exporting NMEA sentences from GPSd.

Here is how I have native meshtastic using GPSd:

$ sudo mkfifo /dev/gpsd-out
$ sudo chown $(id -u):$(id -g) /dev/gpsd-out 
$ sed -i 's|^\s*SerialPath:\s.*$|  SerialPath: /dev/gpsd-out|' /path/to/your/config.yaml
# you can optionally add '-d' to run gpspipe as a daemon
$ gpspipe --nmea -o /dev/gpsd-out
# in a different terminal, run:
$ ./meshtasticd --config /path/to/your/config.yaml
...
DEBUG | ??:??:?? 50 [GPS] Probing for GPS at 57600 
WARN  | ??:??:?? 54 [GPS] Failed to find UBlox & MTK GNSS Module using baudrate 57600
DEBUG | ??:??:?? 56 [GPS] Probing for GPS at 115200 
WARN  | ??:??:?? 60 [GPS] Failed to find UBlox & MTK GNSS Module using baudrate 115200
DEBUG | ??:??:?? 62 [GPS] Probing for GPS at 9600 
WARN  | ??:??:?? 65 [GPS] Failed to find UBlox & MTK GNSS Module using baudrate 9600
WARN  | ??:??:?? 65 [GPS] Giving up on GPS probe and setting to 9600.
DEBUG | ??:??:?? 66 [GPS] NMEA GPS time 2024-08-18 01:01:21
DEBUG | ??:??:?? 66 [GPS] Upgrading time to quality GPS
DEBUG | 01:01:21 66 [GPS] Read RTC time as 1723942881
DEBUG | 01:01:21 66 [GPS] hasValidLocation RISING EDGE
DEBUG | 01:01:21 66 [GPS] Took 66s to get lock
DEBUG | 01:01:21 66 [GPS] Predicting 0s to get next lock
DEBUG | 01:01:21 66 [GPS] 119s until next search
DEBUG | 01:01:21 66 [GPS] gps_update_interval >= 0s needed to justify hardsleep
INFO  | 01:01:21 66 [GPS] GPS power state moving from ACTIVE to HARDSLEEP
DEBUG | 01:01:21 66 [GPS] publishing pos@66c147e1:2, hasVal=1, Sats=8, GPSlock=1
DEBUG | 01:01:21 66 [GPS] New GPS pos@66c147e1:3 lat=<LAT> lon=<LON> alt=151 pdop=2.29 track=200.32 speed=0.00 sats=8
DEBUG | 01:01:21 66 [GPS] onGPSChanged() pos@66c147e1 time=1723942881 lat=<LAT> lon=-<LON>> alt=151
INFO  | 01:01:21 66 [GPS] updatePosition LOCAL pos@66c147e1 time=1723942881 lat=<LAT> lon=-<LON>> alt=151
DEBUG | 01:01:21 66 [GPS] Setting local position: lat=<LAT> lon=-<LON>> time=1723942881 timestamp=1723942881
DEBUG | 01:01:21 66 [GPS] Node status update: 1 online, 1 total
INFO  | 01:01:21 66 [GPS] Sending pos@66c147e1:6 to mesh (wantReplies=1)
DEBUG | 01:01:21 66 [GPS] Sending location with precision 32
INFO  | 01:01:21 66 [GPS] Providing time to mesh 1723942881
INFO  | 01:01:21 66 [GPS] Position reply: time=1723942881 lat=<LAT> lon=-<LON>>
...

# don't forget to cleanup when done
$ rm /dev/gpsd-out

Since the pipe (mkfifo) is effectively read-only, meshtastic's probing fails, but as soon as it falls back to just assuming 9600 baud it gets time and location.

[sgofferj]

@jhollowe
That doesn't work easily in docker or across devices, though.

[jhollowe]

gpspipe can connect to a remote gpsd, so you can have your GPS attached to another computer (or your docker host) and run gpspipe to that host to get the GPS information without needing gpsd or even a GPS device connected to the system running meshtasticd.

Checkout the gpspipe(1) man page for more info.