Hi @AdamJP, I think that you are writing about building a system that is similar to a standard extension to systems like GPS. The technology for GPS is called Differential GPS, https://en.wikipedia.org/wiki/Differential_GPS.
A network of fixed ground-stations with very accurately surveyed locations continually listen to GPS and report the error between their real location and their GPS location. This is then made available to other stations as a correction factor that continually changes for location and time.
I have worked a lot on marine vessels and this is used on all large vessels to correct their location. It is available as a commercial service over radio and satellite from companies like Fugro, https://en.wikipedia.org/wiki/Fugro - for $$$.
So… in my opinion, if you needed very accurate correction to location services you could do something similar over LoRaWAN.
Note: Differential GPS is also used as a security measure in case the GPS system is compromised, etc. This allows a switch to manual navigation for marine vessels. Something similar will be needed for autonomous vehicles.
Geolocation gateway timestamps are ~30ns range of accuracy. (50-100m)
A static node would need gateway grade hardware to determine start of packet in a consistent way to be used for TDoA in conjunction with existing gateways.
The end-device TxDone/RxDone is around +/- 20us of accuracy for determining end of packet and start of the Rx Window.
Using RSSI would add more error than what is available with TDoA with geolocation hardware.
Indeed so, unless the LoRa device itself supported that functionality, as does the SX1280 distance measurment function.
There is going to be a variation in the exact ‘timestamp’ which I would assume is a random feature of the internal hardware and software of a gateway. If it is random or noise related, I dont see how you can apply a correction factor just because you may know exactly where some nodes may be.
@AdamJP No this would not work. The main cause of inaccuracy for the geolocation feature is what is called delay spread: a variation in the travel time of the signal because it is, for instance, bouncing off tall buildings. The delay spread is very typical to the exact position of the transmitter, so it is impossible to use the delay spread of a certain static node to correct the delay spread of node A.
Indeed so. There will also be randoness in setting the timestamp itself.
The random element is not going to be consistent at different times on the same gateway or at the same time on different gateways, so there is in effect nothing consistent to average.
Presume for a minute you know exactly where they are, and trust they never move. How do they help?
With GPS, local receivers sharing the difference between their known and erroneously measured positions helps generate an error map that can factor out ionospheric dispersion, purposeful degradation (back when selective availability was often turned on) and by comparing phase even achieve accuracy beyond the designed capability of the system. But that works because the receiver itself has time of flight capability.
LoRa nodes don’t.
If you scattered around a bunch of ToF-capable gateway receivers, and even if you backhauled them through LoRa and not something else, sure, that could help. But it’s really just like having a bunch more gateways, only perhaps restricted to this purpose only.
But it’s not clear how much having signals from ordinary cheap reference nodes would help the network figure out the error of others.
If you can demonstrate that your known and unkown nodes would experience common distortions of propagation time, you might be on to something. Maybe there’s a case where you get a misleading reflection path off a mountain or tall building and thus know that one gateway’s view of a particular area is indirect and not useful and can discard it.
Ultimately, if you have a test area with multiple ToF capable gateways, and you put some nodes in precisely surveyed positions and watch their measured position over time, you can see if the errors in nearby ones correlate in a way that could lead to generating a common error model - or not.
