# Location by triangulation

Hi,

I’been trying to dig into how to obtain location information of a node. Left and right I’ve seen comments about gateways who are sending it’s own location information (obtained via build-in GPS) but it’s not yet clear to me how to get a location on the node.

For this it seems obvious you need at least 3 gateways and a node. In GPS the end-device would receive the location of the transmitters, an exact clock signal and thus would be able to calculate the difference from 3 sats based in the transmit delay it took to receive the signal from all 3 birds.

For IOT nodes this seems simply impossible, as it takes a fair amount of CPU power to calculate the location. So I suspect it’s the Application Server that needs to calculate the location of the node based on information the node sends back to the network. For this it seems that the node needs to tell the network what distance it ‘sees’ towards at least 3 gateways. For this the gateways and nodes must be exactly timed, so the node can tell how long it took for him to receive messages from different gateways, right? What would the maximum accuracy be of triangulation using LoRa?

Anyhow who can shed some light on this?

4 Likes

in this slideshare, from page 21, LoRa location is explained using DTOA

3 Likes

One problem is of course the data rate. Because you can’t just spam the network full with packets in order to get a accurate location. So if you want to track a moving target, then you’d probably be better off to use a GPS module.

A typical application would be geofencing. For this the node should be tracked at least every couple of minutes in order for the application to determine a breach of the fence.

GPS is out of the question, this requires too much CPU and battery power. This is why LoRa seems a nice alternative.

If you have this situation for example: `(in a real situation you woudn't know the T = 0)`

So the point of interest transmits a signal on `T = 0`, how can you calculate the origin of the signal? For that you’ll need a receiver with an extremely high sample rate in order to detect the time difference. How is that working?

And 2th, how can the different receivers know the exact time? Is it that so accurate?

1 Like

The time between TX and RX tells you how long a signal travelled and thus distance to all stations. Draw circles around each station for each measured distance and find a common place on each of these circles. This is how GPS works too.

The question is: how does a gateway know when the message was sent, as the node does not sent a synchronized time stamp?

Every LoRa gateway have a GPS receiver to give precise timestamping to each LoRa frame received.
GPS has a UART output with the time in seconds and a PPS (Pulse Per Second) 1Hz output that triggers a Timer inside SX1301 that gives microsecond or less precision (I supose 1/32MHz).

The advantage of LoRa modulation is that it is easy to determine the beginning and the end of a bit or a frame, because of the chirp modulation. In FSK it is not easy to determine the beginning or the end of a tone.

In GPS location you know the T=0s and the time of arrival of each satellite and you can triangulate (draw circles with the center in each satellite). The calculation is done in the GPS receiver.

In LoRa you don’t know the T=0s and you don’t know the time of arrival (TOA) to each gateway. The LoRa Network server knows the time difference of arrival (TDOA) between every pair of gateways. If you have 3 gateways you have 3 TDOAs. And if you have 4 gateways you have 6 TDOAs.

Instead of drawing circles to triangulate, you must draw hyperbolic curves with the two focus points in each pair of gateways. The calculation is done in the LoRa Network server, not in the node.

In page 22 you can see an example with 4 gateways, so 6 TDOAs, so 6 hyperbolic curves colliding in a point that is the estimated location of the node.

6 Likes

Radio signals travel with the speed of light `(299.792.458 m/s)`, that would be easy to calculate. And because you know the position of the gateway, you would be able to calculate the position. This is a (probably not mathematical working) example of how it could work:

May a physicist here could make a better (mathematical) example?

Thanks for the example, I now understand it .

So:

1. The node is sending a signal
2. Gateways will pick up the signal and send it to the cloud with a timestamp of arrival.
3. The cloud calculates the calculation with hyperbolic curves.

This slide from the presentation also presents the importance of gateway coverage when using this method of geo-location.

And it will be a killer-feature if we can use this!

Hi @FredH do you have the entire presentation to share?

Hi All,

I intend to create a (Apache Spark) cluster application based on streaming (big) data to calculate the position. I am searching for a Python library which I can use to do the TDOA calculations. Does anybody know a good library?

Kind Regards,

Ruud

I just ripped a few (interesting) slides from http://www.slideshare.net/titidelparis/io-t-sagemcom-m2minnovationworldgeotrackv08 that was shared earlier in this thread by @nestorayuso ! Earlier I urged Wienke to include a GPS in The Things Node on Kickstarter (and still think it would extend and upgrade many usecases for the node!) and then went after geo-localization / triangulation with/on the network. So happy it can be done, but think you at least need a GPS in all the gateways for exact synchronized timing, see this other slide from the presentation by SagemCOM:

1 Like

As you can see in the Kickstarter, there will be GPS inside the gateways:

And yes, localisation would help a lot of killer apps come alive Hope to see an open source implementation ending up in our example handlers coming up some day (any takers?).

1 Like

http://pylayers.github.io/pylayers/notebook/UserManual.html

This is what you are looking for @Ruud ?

Thanks @FredH,

It looks great!

I will update this forum when my application is finished.

2 Likes

Btw: what class will the Kickstarter gateway support? It seems even the Kerlink (the carrier-grade gateway) only supports class A. I was surprised by this.