Sure it could.
But I think it would increase the location accuracy of the Node A as you can draw from a larger dataset of the static nodes, rather than just the timestamps from Node A.
when we sample from a sensor we don’t just do it once… we take averages from the dataset right?
I guess you will find out when you implement it.
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.
Is it down to 1ms?
I have no idea, thats why I asked you earlier.
@johan, @htdvisser, @wienkegiezeman, @RichL is what we are chatting about a viable thing? Love to hear your input.
Cheers
Adam.
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.
Cheers
Adam.
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!!
Cheers
Adam.
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)!
Cheers
Adam.
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.
Thanks.
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?