Meshtastic

LoRa signal-based positioning

Is there any plans for geolocation estimation of devices without GPS from devices with GPS? For example using RSSI, noise and timings to triangulate a devices location relative to other mesh devices?

4 Likes

Not really - but if someone was excited to implement this and sent in a PR I’d happily merge it.

I think it is a low prority for a couple of reasons:

  • Some of the current devices have built in GPS (and future ones will also :wink: ). GPS chips are getting really cheap now.
  • For the devices that don’t have GPS, if they are paired with a phone running the app, the app will provide GPS data from the phone automatically. The device code will use that as a substitute for a built in GPS. The other nodes in the mesh don’t even care that the position came from the device itself or the phone that was helping it. The downside of this config is higher power consumption on the phone.

@iveskins A nice feature suggestion indeed! However, it appears that signal triangulation might be hard to make accurate for low power devices, especially in long range scenarios (as Meshtastic has been designed to be used in). This is due to the problem with estimating signal loss regarding TX, effects of terrain and other circumstances.

https://scholar.google.fi/scholar?q=accuracy+of+signal+triangulation&hl=fi&as_sdt=0&as_vis=1&oi=scholart

It should be doable. All though, estimating or calculating the accuracy (as usually shown as a circle) of the position would be more difficult, than with typical mobile phone triangulation.

1 Like

The idea is interesting.
But! If members of the network Meshtastic need to transfer their coordinates, this is done using the presence of a GPS on the board

But there are times when one of the nodes of the network Meshtastic performs only the functions of a repeater. And he is hidden in some secluded place. No one should know where he is.

1 Like

Good point. There are also some great protocol optimizations that can made in that case. Someday we should make a “Be a router” checkbox which would tell that node to a) power up the GPS only super rarely, b) tell adjacent nodes to increase the weight for routes to this node (because the user knows this node has good line of sight).

Item B is especially important because it will allow substantial improvements to the efficiency of flood routing (which is how most of our packets are sent). This non-naive version of flooding would dramatically decrease the aggregate airtime used for broadcasts.

Adding an issue linking to this thread:

1 Like

It looks like it’s not a simple problem to get high accuracy, and movement with LoRa. As far as I can see data is sent to external servers which employ various algorithms to make predictions. This would all probably require too much resources to do on devices.

The bandwidth employed in LoRa is small (125 kHz), so the recorded times in
the gateways can be the time of a multipath signal instead of the direct one.

The use case I was thinking of, was keeping track of walkers (for safety) on a private forest walking track, that might have GPS dead zones because of valleys.

I think It’d be nice to have two new location concepts:

First is “You’re a fixed node, I’ve told you your location”. It would be ideal if nodes had a concept of a “remote administrator”, someone who can cryptographically authenticate and change settings that others cannot, as per this thread. Although perhaps even this setting should only be a “suggestion”, in case the node walks off (is stolen) and later discovers, via high-confidence means (like bluetooth connection to a GPS-equipped node) that it’s far from its supposed position. (And likewise, a setting for “alarm if location changes” would be awesome.)

Second, is “pseudo-location” fixes, as already described in this thread. Where a node without GPS infers its location based on the RSSI of several other nodes that do have GPS. Obviously if it’s connected over Bluetooth, that counts more strongly, maybe increase the confidence score of the pseudolocation, since the other node (be it a phone, or a GPS-equipped T-beam also talking over Bluetooth) is likely very nearby. But even just using Lora links, having a vague idea of where the roving node is, could help you get in the ballpark and get into Bluetooth range, etc. For when a node you weren’t expecting to become mobile, suddenly is…

There’s another use-case for RSSI-based location, where the real-world position is actually less relevant than the radio-connectivity-based estimate: Geographic routing protocols! Obviously not a thing in meshtastic yet, but there’s plenty of prior art for how location-aware networks can do near-optimal routing without a full view of the whole mesh. Having every node know its “position”, even if not GPS-informed, would pave the way for such enhancements in the future…

However, yeah. All this comes with huge cost in complexity, which likely exceeds the hardware cost of GPS chips. Especially as the latter keeps falling.

The question there is whether a Lora-based estimate would be any better than the GPS chip’s hopeless guess. Modern GPS chips are pretty good even in challenging situations, in my experience.

1 Like