search

meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
2.98k stars 714 forks source link

[Feature Request]: gpsd client support #4009

Open sgofferj opened 1 month ago

sgofferj commented 1 month ago

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 commented 1 month ago

This sounds very interesting!

GPSFan commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

Ahh, any chance of cross compiling?

jp-bennett commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 3 weeks ago

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.