Of course an end-device (node) could have a built-in GPS receiver and send its location. That would make that end-device more expensive, use more electrical power and send more data. But a built-in GPS would also make it independent of being in reach of multiple gateways to (maybe!) allow for location by using DTOA (Differential Time Of Arrival), and possibly be more accurate as well.
Thanks, this confirms my toughts.
So another tought is that due the dutydycle limit it isn’t possible to make a gamechanger for sat navs.
Because we can only send data every 15 seconds. And this wouldn’t be acccurate enough to nagivate your road.
Else we would have low power energy efficient sat navigators.
When using the lowest data rate (SF12; for long distances to the nearest gateway, or for any moving node?), sending 6 bytes for two 24 bit coordinates would need 1.3 seconds air time. So the 1% duty cycle would already limit to sending one coordinate every 131.9 seconds, not every 15 seconds. And along with the 30 seconds/day Fair Access Policy one could, on average, send fewer than one GPS coordinate per hour on The Things Network.
However, location by triangulation also needs the node to send some data to trigger the calculation? Even an empty packet, only sending the 13 bytes LoRaWAN header, needs 1.16 seconds air time on SF12, hence at most 26 such packets a day?
1 Like
On February 18th, Semtech announced:
[…] a next generation reference design platform for its LoRa™ RF gateway that will enable upgraded features, including GPS-free geolocalization for asset tracking applications, and is compatible with existing LoRa network infrastructure and existing deployed LoRa end-points.
[…]
The reference design platform has been licensed to several early adopters for LoRaWAN network deployments in 2016, and Semtech plans to enable more LoRa gateway licensees in the second quarter of 2016.
@johan said during the February 29th Tech Update (at 33’44"):
Regarding the LoRaWAN multilateration, so the localization by nodes: we are waiting for updates from Semtech. Semtech announced a few days ago an update on this.
Currently we have no data of when and to which accuracy we will provide localization. We will provide an update on this soon, I think in the coming weeks.
Problem is that the current hardware is not accurate enough to determine the timestamp of the time of arrival of an individual message. So that means that the accuracy of the localization is very limited, or not accurate enough to actually use in practice. But this is something that the LoRA Alliance is working on, and we are also contributing to this. And we’re doing our best to support localization as soon as possible.
Earlier, @Thomas wrote:
microchip will develop an SX1301 based module for the gateway
And, in the press release, Semtech also states:
The new reference design platform includes additional digital signal processing (DSP) alongside Semtech’s SX1301 baseband processor to enable the new features through a simple software upload.
I find that last paragraph hard to decipher… So, @johan and @Thomas: could the new reference design be an update for the TTN Gateway?
1 Like
Chronos - Decimeter-Level Localization with a Single WiFi Access Point:
The key enabler underlying Chronos is a novel algorithm that can compute sub-nanosecond time-of-flight using commodity WiFi cards. By multiplying the time-of-flight with the speed of light, a MIMO access point computes the distance between each of its antennas and the client, hence localizing it.
[…]
Yet, emulating a wideband radio using packets transmitted on different frequency bands is not easy. Stitching measurements across such packets requires Chronos to overcome three challenges:
Resolving Phase Offsets: […]
Eliminating Packet Detection Delay: […]
Combating Multipath: […]
The body of this paper explains how Chronos overcomes these challenges, computes the absolute time-of-flight, and enables localization using a single access point.
1 Like
I’m curious to know what the background for this claim is. Could you elaborate? For me it seems the opposite would be more intuitive:
- Fixed nodes have a (fairly) constant path to the gateway and the data rate could therefore be configured once (no need for ADR).
- Mobile nodes constantly change their distance to gateway(s) and therefore needs to change the data rate to ensure it transmits with an appropriate data rate for its current position.
I can see two arguments for fixed nodes using ADR:
- Nodes can be deployed at different locations with the same configuration and automatically optimize their data rate.
- Allows deployed nodes to automatically optimize data rate when gateways are unavailable, removed or added.
I think there is a misunderstanding of what ADR can deliver.
- ADR is a very slow process which can be added to each packet. If you are moving and at one time you are close to the gateway and then get the message to send less power next message you are further away but sending with the smallest amount of power, your message won’t be received. So that is why ADR should be turned off in case of a moving node.
- When you have a fixed position node ADR can optimize your link and power consumption. There is a need for ADR because when the node joins the network it doesn’t know how much power it should use.
2 Likes
Just for future reference, from the Kickstarter Project Update #9:
The TTN gateway will not include a GPS module (but will have Bluetooth 4.2 and an XBee interface). So, if ever needed, it needs to get time synchronisation from the internet, not from GPS.
We were hoping also to announce we would support positioning over LoRaWAN. But as the current LoRaWAN specifications and chips do not allow positioning to properly work we will not add this feature.
[…]
Positioning over LoRaWAN
We would have loved to offer you the potential positioning features as a third extra as well but this was unfortunately not possible.
This would have been a very nice feature we worked hard on to include. But due to the lack of support in both the LoRaWAN chips and specifications this is not possible at the moment. Please find below our considerations with regards to this topic.
When we started out with the gateway design we wanted to make the specifications comparable with all LoRa gateways out there, only for a fraction of the price. When doing our research and testing different gateways we noticed a lot of them had, or had place for, a GPS module. This GPS module is intended to enable triangulation based on triangular time of flight calculations as well as to sync the internal clocks over GPS. With a rather complex set of calculations one could, in theory, calculate the location of a node in a LoRa network.
That looked very promising. Well the problem is that this is in theory and after some thorough testing we have concluded that the current version of LoRaWAN compliant chips are not capable of providing the information required for calculating usable positioning data of the nodes. We always saw this as a future possibility and while not pitching localization use cases in this Kickstarter we felt the strong need to explore this possibility.
Since we started working on LoRa more and more research has been carried out on this localization challenge it is now safe to say that with the current layout of components that all available gateways use it won’t be possible to carry out triangulation and still be LoRaWAN compliant. There is a new reference design currently being developed by the LoRa Alliance with better support for this functionality. There are no guarantees that this will be achieved or if so in which time frame.
The way we see it, we had 2 options:
Option 1, wait till this new design is finalized, pushing our deadline easily another 12 months, but do the best we can and support the feature of localization, with no guarantees that it will be even possible in this new reference design. So extending the delivery to an unacceptable date for an add-on of which does not yet have proof of working.
Or option 2. Stick to our deadline, and stick to the current reference design we have always been using, make it the cheapest, best working, plug and play, open source LoRaWAN gateway available to start building this network.
We choose option 2 because we are not prepared to accept an uncertain delay for an uncertain design feature; leading us to the conclusion that the use of the GPS chip for this purpose in our gateway has been rendered useless.
Good to know is that for the ones that had a use case in mind that required positioning. It is still very good possible to make it with a GPS chip on your node. These products are emerging at the moment and are easily to find.
1 Like
Geolocation availability has been announced by LoRa Alliance. Please have a look at www.linkedin.com/hp/update/6154506865356070912
1 Like
I think that refers to Semtech’s June 30th announcement? Then I’m afraid Semtech wants money for its usage:
How to Get LoRa Geolocation
Contact your Semtech sales representative for more information and to implement the LoRa geolocation solution today.
Still then: good to know it’s possible with the proper gateway hardware.
As far as my analysis goes, Kerlink has developed the technology and there are some agreements with eighter LoRa alliance and/or Semtech to diffuse their invention. So you might expect that Kerling gateways are the ones to support it initially and they want to be paid for that. Not that unique for a commercial organisation with an IP protected business model.
The technology is not new. Geolocation uses TDOA: Time Difference Of Arrival.
When the time is known at which the signal is received at the gateways, the network can determine the time difference it took to arrive at two gateways. Calculating the distance in this way is easy - a few hyperbolic equations are easy when you know math 
The problem is that the radio waves travel 299.7 meters in 1 micro-second, so an accurate timing reference is needed in order to determine the position with some accuracy.
There are GPS systems that are able to create such a time reference signal. They provide a 1PPS signal (1 pulse per second) that can be accurate up to 40 ns. This makes it possible to determine the absolute time at which a signal arrives at the gateway.
That said, most GPS receivers do not provide such an accurate timing reference so it is not that easy to make this technically possible and most current (TTN) gateways do not even have a GPS.
The current protocol gives the “absolute” gateway time in micro-seconds but even with two gateways with GPS at the same location they do not provide an accurate time that is usable for geolocation.
Most likely Kerlink, together with SemTech are able to get the timing accurate enough for geolocation. But if this uses the current sx1303/sx1257 chipset or if they developed a new baseband chip for this I do not know. But I am almost sure that current gateway boards, even with GPS, are not able to perform geolocation with the accuracy mentioned.
If the exact locations of the gateways are known, and the gateways have reliable clocks, the network could determine the clock-time difference between two gateways by having a gateway send a message with its current, microsecond, time to the other gateways. The other gateways forward the message to the network with their local, microsecond, time of reception. The network can calculate the expected transit time based on the distance between the sending and receiving gateway and calculate the reported transit time (time of reception - time sent from message). The clock-time difference between the two gateways can then be calculated by substracting the expected transit time from the reported transit time.
The clock-time difference can be calculated for each gateway, giving a microsecond precision reference time that can be used for geolocation.
In order to make this work, a gateway must send a message containing its local time every time it adjusts its clock.
Problem is that 1 microscecond is ~300m That’s OK for some applications, but would hazard a guess that it’s not that great for most.
I just got the data for a new GPS module: 10ns accuracy on the 1PPS signal. With a 40 MHz 0.5ppm oscillator that gives a 10m inaccuracy for one measurement. With more gateways the accuracy levels out so 50-100m accuracy is possible using this technique.
But this is based on open field signals. As soon as there are buildings this changes. The buildings echo 868MHz signals very well. I did some tests with a simple directional antenna. The direct line is blocked by a few buildings and the signal improves when I use my old billiard skills to bounce of a building on the other side of the open area (and that adds around 150 meters to the distance)
What I don’t really understand about the theory is how gateway clocks are synchronized. A synchronization signal would also have to pass different routes to each gateway (I guess by normal internet?). How can you determine precisely enough how long that takes?
See for example this article. So using a GPS pps signal each gateway can “autonomously” get a synchronised clock (at least not depending on the network / NTP)
that’s pretty straightforward. Nice way to solve it.