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
). 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.
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.
2 Likes
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 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
Been thinking about static and mobile node linking structures for quite a while , and how i would implement this as i was creating my own mesh concept .My idea was a time to respond based bidding system for forwarding. For example Node 1 broadcasts the msg from the originator phone . Node 2 hears msg and waits a time scale to reply based on it’s how much air time it has remaining, how far it’s GPS location from Node 1, longer distance being a better faster response, how many other nodes static repeater nodes it has heard in a time frame. Node 2 listens for node 1 to acknowledge any other repeater while it is waiting it’s time value score bid. If no other repeater acknowledges node 1. Node 2 sends an acknowledge that it will handle forwarding the msg as it calculated the best choice in area to forward msg. Node 1 sends an agree ack to node 2. Which all other stations local to node 1 would also hear and know the packet is being routed by another node (node 2) because they lost the time to respond bid. So those waiting to bid for the packet stay silent and not waste any air time. Node 2 reduces the packet hop count and then broadcasts the msg waiting for an ack form another node. in the area Node 1 does not acknowledge back
because it has a copy of the packet in it’s sent list rolling packet forwarding buffer. Also node 1 now knows it has now successfully passed on it’s msg as it can hear node 2 trying to forward it. Other nodes that heard node 1 original msg but lost the bid to forward it also stored the packet in their rolling heard buffer.They therefore don’t respond to forward the msg from node 2 as they were not picked before as the best routing choice by node 1. Node 2 although the best choice at the time, tries to send the msg for another node to ack and forward it. Each time it waits. if it hears no bids to forward the msg node 2 counts down an internal fail to send counter. if it gets to 0 then it sets the hop counter in the packet to a hot potato value 255 as it gets desperate to move it on . Which tells any node to bid by the quickest time to forward the packet even if they have it already in heard or forwarding buffer, putting in a faster bid time if they don’t have the msg in their buffer meaning they are a new potential route. Or responding quicker if they have it in there receive buffer.rather than been part of the forwarding chain., this also gives a potential for a new routing direction. The packet would have the hot potato flag until a new station that has not received it ever before could then assign it a new hop value of 7. the bid time delays of nodes could be dynamic based on traffic and nodes in the area. allowing for optimum throughput of data.
Triangulation of RF source need a precise time reference, usually cheapest way to get this is by using GPS, you get a 10-100ns accuracy if i recall correctly, so your plan will and only work if you have a cheaper and better global time syncing method.
sorry for that. and please correct me if you think i am wrong.
If GPS is down or you are presuming a total calamity, and budget is not an issue, you will need a MIMO SDR receiver/Antenna Array to utilize MUSIC or similar algorithm to find the RF source direction.
You can google some youtube video with GNURADIO, GPS anti-spoofing, MUSIC etc.
1 Like
LORA time of flight would be the way to go. The radios measures time between sent and received and can be converted to distance.
Some of the radios should support it.
People have tired it and the results are usually disappointing. If you don’t have 3+ nodes with known locations you can’t get a fix, even then the fix isn’t very accurate.
One of the biggest confounding factors is multi path and reflections of radio wave transmission. Unless you have a true line of sight path there is a significant chance you are picking up a reflection that could have a longer path then a straight point to point that the trilateration math assumes.
2 Likes
The 2.4GHz LoRa chips (SX1280) support a ranging function that could be used here.
In my not so humble opinion (sry!) any non GPS based location features shouldn’t be even considered until well after a 2.0 release.
The time and effort required doesn’t really match the benefit gain for the majority of users and use cases.
The best use case I can think of where this a significant benefit in hardware cost, size, and power consumption sans GPS would be tracking live stock. The collars could have a minimal radio package and the area they are located could have 3+ nodes around the periphery to establish a geo fence of the area to be monitored. But that would probably be much simpler and faster to implement as an independent project.
Perhaps that new project could utilize Meshtastic for the edge nodes and forwarding of messages, in that case Meshtastic would only need to respond for position requests with the needed Time Of Flight headers present and a forwarding module for devices that don’t implement the full Meshtastic device stack.
2 Likes
Totally agree ;-). 1.0 is almost done, but after 1.0 we have other good ideas (see other thread and wiki) that IMO are way higher priority than this. If some particular person wants to code this and it works would be open to a PR.
4 Likes
lol version 2 being code for ?. i will delve deeper into Meshtastic , as yes new to this project. But from what has been described, flood mesh transmission( all stations repeat the packet is a potential waste of transmission time) This will eventually restrict the size of the groups mesh and bottle neck to stay within limitations, and therefore restrict opportunity to forwarding between groups.As a mesh it should be dynamic and efficient at routing from originator to destination. Packet radio X25 in it’s day for example. Have to be honest never knew the nuts and bolts of it, but was impressed by it’s efficiency and robustness. I can see this concept being implemented into phones but only if the mesh can route between groups , well until starlink is up and running, which i doubt will be free.