is it possible for a node to determine if geo location is possible on that specific location, ‘how many gateways do I see >3 = ok ?’
@Arjan I don’t fully agree about not using GPS in nodes: you could have the GPS turned off completely and let a another sensor (movement, change of angle, noise) be the trigger to turn the GPS on and send the location of the node. Using the bi-directional possibilities of the network to let energy-friendly sensors trigger other, more energy consuming sensors and switches+devices, is the way to go for many smart usecases and still have nodes that run for years on an single battery charge!
2 Likes
@FredH in the situation that geo localization by the network is not possible, because there are not enough gateways in range, a gps unit can be switched on.
but that would be a cold start and therefore A- timeconsuming to get a sattelite fix and B- using a lot of energy
I agree that depending on the purpose of the node, there could be also an GPS unit onboard.
1 Like
Not using just the base LoRaWAN specification and packets. Multiple gateways might receive a node’s packets, but only a single gateway will reply (selected by the backend servers). I do not believe there is some kind of “gateway ping” packet defined, gateways will AFAIK never send packets on their own, only when told to do so by some backend server.
To let a node know about localization possibilities, the backend server should figure this out and use some application-specific packet to tell the node AFAICS.
1 Like
another good article, including RSSI Heatmaps, RTT and fingerprinting…
2 Likes
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?)
2 Likes
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.
2 Likes
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
1 Like
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?
1 Like