Hi All,
There is a RSSI Geolocation integration that is provided on the TTN Integration with using the Semtech services.
This service uses the RSSI and the TOA to calculate the position of a device, just integrated it to my first application.
Are this algorithms know?
PS. I do understand using the limitations of this type location calculation, I want to use it more as if my device gets feet I can locate it within a few (100) meters
There was an early Colos integration that leveraged the capability experimentally where TTN participated - since comercialised by Semtec et al. In reality it requires specific S/w build and GW configs (licensed for a fee) with GW’s needing special build with precise timing support (to allow synchronisation/TOA/TOF correlation) - note 1uS error in timing is approx 30cm/1’ distance error, and with typical internet connected devices seeing errors of many mS even 10’s mS that is a big miss and needs compensation - from GPS or IEEE1388(?) realtime ethernet/network type implementations and use of TCXO’s etc…
Havent looked at latest implementations but IIRC there was plan under Colos to blend data/loacation sources e.g also mapping to know areas with given WiFi SSID etc, (such as captured by Google Street maps vehicles!), adding in GPS/GNSS sources and also SMTC has introduced specific LoRa device silicon and ref designs (LL1100? I need to go look it up), again with supporting cloud services…
Update remembered its the LR1110 - close!
This is one of those features, RSSI location, that if it returned reasonable results then you would expect lots of people would be using it, lots of applications etc.
The reality of RSSI location, in the average environments where gateways are, is that it just does not work to any precison that makes it worthwhile.
In the urban area where I live, I can be 500m away from a transmitter and receiving one signal level, go across the other side of the rode which is only 10m away and the signal drops by 10dBm. So in RSSI distance terms I am now 1500m away from the transmitter. This variation in signal strength over short distance is common in built up areas.
And as for the TOA capability of standard gateways, I recall an ocaision when someone posted the reception logs for a node from 3 gateways that happened to be in the same room. I forget the exact distance but in TOA terms two of the gatways were several thousand kilometres apart, out of this World really.
Good method if you are in towns or buildings, can also use BLE bacons in buildings and rooms, I am out in the ‘Sticks’, a WiFi hot spot is a scares commodity 
Yes, RSSI can not always be used as a accurate measure of distance, if the medium is not known what the signal travelled thru or if it is a reflected signal, accurate known gains of antennas and accurate power reading of the TX or RX signals. It can thought give you a fairly good indication if you are very close to the source of not. And possibly could be used as a validation that you calculation position is fairly accurate (several 100 m or my be less, I am using all the term very loosely here).
With TOA you should be able to calculate to 300 or better if the time stamp is uS and you have at least 3 gateways (timestamps) or more.
The gateways would need to be synchronized (time or GPS clock) to get any sort of accuracy.
Any one with experience in witch gateways have good synchronization?
In the “rx_metadata” there is a “timestamp” value, is this the TOA?
The “rx_metadata” “timestamp” value, where is this generated? The gateway, network server or ???
This “timestamp” value seems a bit random to me.
Are the algorithm use by Sentech know, as it seems according to the documentation they use RSSI/TOA to calculate location.
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "on-the-hill-01",
"eui": "00800000A000104F"
},
"timestamp": 2792409836,
"rssi": -65,
"channel_rssi": -65,
"snr": 9.5,
"location": {
"latitude": -29.806432,
"longitude": 30.771859,
"altitude": 402,
"source": "SOURCE_REGISTRY"
},
"uplink_token": "ChwKGgoOb24tdGhlLWhpbGwtMDESCACAAACgABBPEOyVw7MKGgwIydT6iAYQrNKkywIg4NPixKK/Bg==",
"channel_index": 7
},
{
"gateway_ids": {
"gateway_id": "tech5-alverstone-02-dbn",
"eui": "313330374E005900"
},
"time": "2021-08-19T19:00:25.461028Z",
"timestamp": 774405913,
"rssi": -115,
"channel_rssi": -115,
"snr": -5.75,
"location": {
"latitude": -29.770195,
"longitude": 30.716669,
"altitude": 950,
"source": "SOURCE_REGISTRY"
},
"uplink_token": "CiUKIwoXdGVjaDUtYWx2ZXJzdG9uZS0wMi1kYm4SCDEzMDdOAFkAEJn+ofECGgwIydT6iAYQ8IyYywIgqPPB8cSjzAE=",
"channel_index": 7
}
Very unclear what you are suggesting, since TOA location is rubbish with current Gateways.
Sure if all the Gateways were changed to be synced locally to GPS time then TOA location could work, but such a major overhaul of the Gateway network seems highly unlikely.
I dissagree.
With a typical Gateway having an antenna on a highish building, you might get fairly weak signals if the node was geographically close to the antenna but at gound level.
Whereas if the node was 10 or 20 times further away but with line of sight to the gateway with no obstructions in the way the signals could be stronger.
So all that RSSI location can really tell you is that you might be close to the Gateway or maybe your not.
If someone creates an open source alternative to Collos (/LoRa cloud) they should name it Schrödinger 
To be fair, I assisted someone who tried to use the LoRaCloud RSSI only calcs and it wasn’t exactly accurate but with three gateways it got the general location - not much better than a GSM mast fix, but sort of.
On the other hand, there is nothing like trying to warp time & space to get some new novel marketing material out of a solution.
If I have a 100 football pitches, I want to know on which football pitch the device is. I am not looking to put it down to where a penny is laying on the football pitch.
Looks like I will have to sharpen my trig skills
More than that, it’s a geometric circle intersection.
You may want to read the book I published in 1637: La Géométrie
Do you recommend your first or second edition 
Depends on what you can get hold of, you’ll probably only need Book 1.
But please be aware, my views on helping with the details haven’t changed much over the years, on the Wikipedia page they summarise it well: I write “I did not undertake to say everything,” or “It already wearies me to write so much about it,” occurs frequently. I justify my omissions and obscurities in order to give others the pleasure of discovering [it] for themselves.
But @Johan_Scheepers, in all this discourse, you may have missed the reference to the online service that LoRaCloud provides to do the calculations for you.
I have integrate that service already, but I want to run it locally if I can.
That red bus is actually a temperature node, and the position is dam close to correct to <75m if 3 or more gateways pick it up. When 2 gateways see it accuracy drops drastically.
Want to run for a few days and see.
Oh you are funny, thanks for keeping me amused! Two circles intersection have two contact points (draw two overlapping circles)!
Three give a theoretical single point of intersection but if you get four gateways, you’ll find it draws an area out - which if you are lucky will be about the size of a football pitch but equally could be a km in radius.
If you can get 6 gateways on 6 high buildings and do some war-driving, you could probably get enough data to create your own algorithm.
What’s wrong with the online service?
Learning to play the violin, ever project adds
I’ve got it in my mind to make a determined effort at that but record it for when I talk about learning!
IIRC some of the early LoRa testing and early Collos presentations and fundamentals of the LoRaLoc stuff its not just a simple 3 circles type geometry triangulation/implementation. I seem to recall that the way the system works its better with 4 or more GW’s ideally in near square grid, with best results ‘inside the box’ - with accuracy falling away rapidly as you move outside the box. With careful placements, optimum distance between GW’s and a following wind I recall data suggesting anywhere from 20-200m placement accuracy - summed up as ok at block level…! If the square is elongated to a rectangle then the error also scales in the stretch direction with potential location/error area also stretching in similar scale. Also precision increases with frequency so EU 868 better than CN 470, US915 sightly better than EU868, and AS923 slightly better than US915… with 2.4Ghz showing good promise 
In very early days we had fun with a special p2p FPGA enabled ToF demo (think it was at 2.4Ghz) inside buildings where we demoed to customers playing a game of hide & seek Tx and use Rx to play hotter hotter, colder colder type game to demo capability…we could get it down to inside a room and which side of room… a bit like Star Trek Wrath of Kahn it was sometimes funny to see how many customers/testers “failed to think in 3 dimensions”, if Tx hidden v high or v low!
Obviously the block level stuff was for smart city/big asset tracking apps (which street is the bus or rubbish truck on) the in-building stuff was a hope for “which room in the hospital is the specialist in or a bit of expensive mobile medical kit etc”., “where is that pallet in the warehouse”, or blending “where around the airport apron, service area or buidings is x kit/person”, similar in quarries/mines etc…
I’m hopeful we will get there one day… I think data fusion with GNSS, WiFi sources and e.g. deployed BT beacons providing augmentation is likely way forward.
First is the understand the time stamp of the gateway for the TOA, @johan can you assist on this?
On some of the location methods they use both the TOA, SNR and RSSI to calculate the location, as in the algorithms that Senmtech utilizes.
They also averages out the position over several measurements, multiframe lookup.
https://www.loracloud.com/documentation/geolocation#
https://www.diva-portal.org/smash/get/diva2:832144/FULLTEXT01.pdf"
I’m not sure he will want to buy you a set of gateways with the TOA functionality - last I checked they were in the £800 price range - so perhaps best not bother him with this project.
So if you want to use speed of light calculations you’ll need a bunch of those top end gateways with a really top end GPS receiver on each.
The time we get is the time reported by different elements of the infrastructure along the way which, due to the aforementioned speed of light, needs to be at the nano second level to become vaguely accurate as 3ns = ~ 1m. The concentrator card actually uses time travel to figure all this out as after it has received the uplink it goes back to figure out when it was first heard based on the processing that was done to extract it from the airwaves.
If you want to have a hack at using the RSSI, then you can come up with your own algorithm and compare it to the API service on LoRaCloud.