I don’t know whether I have got this wrong but can you only get accurate positioning if the gateways hold accurate synchronisation from a time-server - usually a global satellite navigation system?
I asked this to Kerlink regarding triangulation and their response suggested it isn’t possible with their gateways at the moment.
For DTOA (Differential Time Of Arrival) each gateway receiving the packet must me in sync with the others, else it’s not possible to tell who got the packet when and what the difference was. The method of syncing is arbitrary, but any satellite navigation system (GPS refers to the US system only, Gallileo, Glonass are not the same as GPS) would be a good source, imho.
Hi all,
I want to try to calculate the location of as much as possible sensors in a area, (world?) 24 hours a day. I have a hadoop cluster with, Spark and Nifi which can do this. Who can give me more informattion how can recognize sensors and gateways on the Internet?
Greetings,
Ruud
If a node is within the range of multiple gateways: wouldn’t fewer gateways receive that node’s data if it uses a high data rate?
Adaptive data rate makes a node use a lower rate for longer distances between the node and the (closest) gateway, right? Then I assume that if a lower rate is needed to reach some gateway, a higher rate would make the signal not get to that gateway, right? Turning that around: if a node happens to be close to one gateway, its high-rate signal might not make it to gateways that are further away, making it impossible for the network to calculate any position…?
(Please tell me I’m wrong! Or maybe low data rates are mandatory when positioning is needed?)
Adaptive data rate must be only used for static/fixed nodes. If you use a moving node you must disable ADR and use slowest DR (SF12). In this case more gateways will receive the data but higher power used.
A node you need to locate is often a moving one, not a static/fixed one.
And as seen in the slideshare, SF12 gives better accuracy than SF7.
About RFI Engineering simulator, a SX1301 has a 32MHz clock source, it gives a timestamping resolution in the PPS signal of 31.25ns or 9.375 meters in linear location.
(1/32MHz=31.25ns)
(31.25ns * 3E8 = 9.3685m)
(3E8 = 300000000m/s = speed of light)
A timestamping error of 500ns can be taken as good approximation (error and resolution are different concepts). It gives a error of 150 meters in linear location for every pair of gateways. The simulation results look good. There are more gateways in Amsterdam than Rotterdam and messages are received by more gateways. Location in Amsterdam is often more precise than Rotterdam, but if the gateway constelation is not favorable, it can be very imprecise.
Does this only apply if one needs location by triangulation, or is it a general rule of thumb for moving nodes?
(I expect the latter: any data rate that was suitable for some location, might be too high after the node has moved away from a gateway, in which case data might be lost?)
militairy use a system called NAVSOP (Navigation via Signals of Opportunity)
yes, to disable ADR is a general rule of thumb for moving nodes
Just for future reference (not my cup of tea): some have different experiences with using low data rates for moving nodes.
So Its not using GPS satelites for the location?
Correct me if i’m wrong.
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?
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?
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.
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:
I can see two arguments for fixed nodes using ADR:
I think there is a misunderstanding of what ADR can deliver.
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.