Is it down to 1ms?
I have no idea, thats why I asked you earlier.
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;
Perhaps contact Richard direct ?
Hey @RichL get in here!!! We have some sciencing to do!!
- What is the precision of gateway timestamps, ns/ms/s?
- Whats is the impact of static node location whilst computing geolocation?
- Are you coming to TTN Conf Adelaide?
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.
Thanks @cultsdotelecomatgmai, sounds like you have a cracker of a job buddy, sign me up!
And also … I’m not crazy(er than usual)!
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.
I can see that sort of accuracy is possible if your using the GPS PPS to sync time, so is that how they do it ?
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.
The sx1301 with gps pps provides only +/- 20 us accuracy called out in lorawan downlink timing.
Additional hardware is use to determine the fine timestamp with ns accuracy.
So a standard Gateway provides Geo-location to circa +/- 6km.
Is the required hardware an add-on, or must it be built into the Gateway board itself.
It is built-in.
@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.
What are static nodes used for?
In the context of this thread, it meant a node that was known to be fixed in position and that its actual location was known.
As apposed to nodes that could change position, when used for tracking assets for instance.
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.