The key bit of information is the resolution\stability of the current timestamping, if its say only down to 1mS, then your trying to average a location that could be +- 300km, which I doubt would be meaningful.
While I can understand where you aim, the geographical position of static nodes not owned by you is not something you sample to reduce the error - position will be likely set statically (like already you can do in console), and nothing prevents voluntary mispositioning. The same is valid for gateways of course. On the other side, if you plan to build a strictly controlled infrastructure, at least static nodes position will be right (to which you have to add the time resolution issue…).
Thanks @UdLoRa, I think I was more on the path of only sampling data of “static node” that we own for this theoretical case study, there for the location of “our” static nodes would be accurate.
Sorry for all the questions, but I still think there is something in it.
To get a decent resolution of postion you need to timestamp to a sufficient resolution also. To then get accuracy you need to sync the gateway time accuratly, that should be possible using the PPS from the GPS.
Once you have done that, and the packet is seen by at least 3 gateways, you should have an accurate geolocation. If you do that then adding extras nodes will add little extra benefit, I would think.
TTN are thinking about these things, I saw this presentation at TTN Conferance 2018;
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.