Sticky

LoRa | Geolocation

  • 4 november 2016
  • 59 reacties
  • 10796 keer bekeken


Toon eerste bericht

59 reacties

Reputatie 1
Badge +1
I have geolocation provisioned and sending with SF12 and ADR off as advised by KPN in this thread. I find that quite regular my signal is received by 3 or 4 gateways, but only occasionally the geo position is updated. I can send dozens of messages per day and still find that my calculated position may be two days old! Is my observation correct that there is not always a position update when a signal is received by 3 or more gateways? Or am I doing something wrong?
Reputatie 1
Badge +1
I have another question about geolocation: I guess for the best results and accuracy, it's beneficial if as much gateways receive your signal as possible. At least more than 3. However, if one gateway receives your signal quite strong, it will ask the device to tune down, meaning that less gateways will receive the signal, and the geolocation accuracy will deteriorate if at all enough gateways recieve the signal for a position determination. I guess in the long run KPN doesn't want any devices that ignore mac commands and keep sending at SF12 and max power to get the best geolocation results. How are these mechanisms planned to co-exist in a sort of optimum configuration?
Reputatie 1
Badge
However, if one gateway receives your signal quite strong, it will ask the device to tune down

Why do you think so?

BTW, a gateway typically is just unable to send a MAC command to a node, as it doesn't have access to NwkSKey.
Reputatie 1
Badge +1
However, if one gateway receives your signal quite strong, it will ask the device to tune down

Why do you think so?

BTW, a gateway typically is just unable to send a MAC command to a node, as it doesn't have access to NwkSKey.


Or then more generally speaking: the network functionality as a whole (ADR) is aimed at preserving link budget; the way it works does not change anything to the nature of my question, or does it?
I would like to test with geolocation. Is this possible? What do I need to do for that?
Reputatie 1
Badge +1
@Gijs you need a LoRa subscription with the feature Geolocation activated. Then you need an application that sends some data (even if it is a dummy payload, so no specific changes needed in your application), then you need to make sure that at least 3 gateways can pick up your signal for triangulation, so you need to check your antenna effectivity, TX-power and SF, and then you will receive a new message type on your backend server, the DevEUI_location message that you need to decode. That's basically it 😉
Reputatie 7
Badge +11
@rharte thanks so much for your detailed explanation about Geolocation! 😃

@Gijs at this moment, we don't offer Geolocation test accounts anymore for the developer portal. This is because we are busy launching the feauture globally! You may expect to use it on the developer portal within a few weeks from now. This also applies for Thingpark, the subscription portal.
@Tim and @rharte
Thanks for the information. I can't wait to test with the geolocation funtionality. What can I expect from geolocation inside buildings? I am looking for an indoor solution that performs better than gps location.
@Tim A quick question:

Supposing my sensor is well within range of loc-enabled stations, could it be possible that I am not guaranteed to receive an update on each transmission because, for instance, the backend hasn't quality data to compensate for external factors (e.g issues of multi path or whatever the DTOA issue might occur).

My question boils down to understand if more than one transmission might still be required even in optimal network coverage of location-based gateways.
THX
Reputatie 1
Badge +1
@Gijs You can forget better than GPS accuracy, the only thing you may achieve is better than GPS coverage. I think KPN strives for 20-50 meter accuracy, but they are not there yet. The actual accuracy depends on the geometry of the network, which is still changing from day to day because KPN still expands the number of sites, and it also depends on your location of course.
We have done a lot of tests and as a rough estimate I would say that in 80% of the cases, the accuracy lies between 20 and 200 meters.
Statistically, I would say the outdoor accuracy is better than indoor. Simply because the reception level indoor is less, this means fewer gateways receive your signal, and the triangulation quality is less.
Reputatie 1
Badge +1
A question for KPN: does geo-location also work if you send a message with an empty data-payload, carrying for instance only a MAC command?
@rharte Well put. That's an additional aspect I wanted to tackle.

I have the impression we can't possibly correlate location with a data transmission (that explains also why it's advertised for stationary objects).
For example, a JoinRequest might trigger a position update, yet no data payload is sent. The device might move, in the meanwhile, and end in a zone where multipath prevents location data to be computed effectively (i guess some kind of outlier filter is implemented). However the last known position would still be the one computed at JoinRequest time.

Am I completely off path?

One wonders if a LinkCheck might thus trigger a location update.
Reputatie 7
Badge +11
@rharte very well explained! I'm not sure yet about retreiving the location with only a empty data-payload. We will ask our specialists about this and come back at you.

@Gijs, I have to agree with @rharte on the LoRa Geolocation vs GPS. Only in a situation where you don't have a GPS signal at all, LoRa Geolocation might perform better. For all other situations, GPS would always be more precise.

Hello @Gabzz, I'm not sure if I understand your last question, could you explain the question? Would you like to know what happens if a new location can't be computed, the last known position will be sent?
@Tim Sorry for not being clear enough.
What I wanted to say is:
Is there a situation where the backend needs more than one transmissions to compute a location? I suppose the answer is yes because my device might be able to send data but TDoA might fail because of harsh multi path environment (i.e. a densely built area for example). If the gateways gets numbers that are totally banana the backend might decide to treat them as outliers and not compute.
The result from the user PoV is that data is safely transmitted but no new location is computed (and the location timestamp remains the old one).

If, by chance, the backend decides instead to use a Last known location and, yet, it updates the Location Calculation timestamp or, worse, it sends a location message out, that is quite against criteria of data accuracy, consistency and timeliness.

I am sorry for this wordy response but I can't make it simpler. 😞
Reputatie 6
Badge +6
Hi @rharte,

Just to be sure I discussed your question about an empty data-payload with Geo-location with the specialists. The size of the payload has no influence on the calculation so it can be 0.

@Gabzz Thanks for clarifying your question. I understand what you mean now. I am going to discuss this with the specialists. When I got the answer, you are the first to know 😉
I expect to get an answer by Monday.
Reputatie 6
Badge +6
Hi @Gabzz,

Below, the answer that I got from the specialists:

Yes, a situation may arise that the message is received on less than 3 gateways, or that reception signal differs so much that it is not relevant to the three-point measurement.
In that case, no update of the location will take place, but this will be reversed by the time-stamp DevLocTime (and the absence of an update).
@Rick S. THX
Perhaps it's me but I find the wording ambiguous:
"but this will be reversed by the time-stamp DevLocTime (and the absence of an update)."

Means that neither an update is used nor the time-stamp is updated (to the failed computation time) in the next "data-message". In that case the response is accurate and consistent. Do I understand well?

Sorry, it's an old man typing here 😉
Reputatie 6
Badge +6
Hi Gabzz,

I agree with you that It is a bit difficult, but you understood it perfectly!
If I can help you with any other questions, please let me know 😉
Reputatie 1
Badge +1
@Tim, @Rick S., I have a question that I posed earlier, but never got an answer on:
I understand that the network calculates a position if 3 or more gateways receive a device's uplink message. I see, however, on numerous cases that there is no DevEUI_location message received by our backend, even though 3, 4 or even 5 gateways receive the uplink signal. As I see it, this makes the geolocation feature quite unreliable.
Can you please explain what the logic is when a position is calculated or not, and why DevEUI_Location messages are often not generated even when an uplink message is received by plenty of gateways?
Reputatie 6
Badge +6
Hi @rharte

My sincere apologies!
We completely missed your question at the time 😱
I'm sorry to say that I don't have the answer right now. This means that I have to turn it back to the specialists. I will discuss this right away so I have an answer to the question as soon as possible.

To be continued!
Reputatie 1
Badge +1
No worries @Rick S. 😉

I have an observation along the same line that I would like to check with you: sometimes we see a position update but no DevEUI_location message! Let me give an example (and apologies for being quite comprehensive):

- At 02:00 we send an uplink messages that results in a position update. Immediately after the DevEUI_uplink message we receive a DevEUI_location update message (as expected)
- At 04:00 we send an uplink message that is only received by 2 gateways. There is no position update and the DevLocTime in the uplink message refers to the 02:00 position update (as expected)
- At 06:00 we send an uplink message that is received by 6 gateways. There should be a position update but there isn't any DevEUI_location message received, and the DevLocTime in the uplink message still refers to the 02:00 position update (not as expected)
- At 08:00 we send an uplink message that is received by 2 gateways. Again no position update but suddenly now the DevLocTime in the uplink message refers to an 06:00 position update!

So that means the netword did in fact calculate a new position at 06:00, but a DevEUI_location messages was not sent. We went through our logs in detail to make sure we didn't miss a DevEUI_location message but that was not the case. Also we notice that the FCntUp skips a number every time a DevEUI_location message is received and that was here not the case. So we think we have quite a strong indication that the network sometimes updates the position without sending a DevEUI_location message and the only way knowing is to compare the DevLocTime in subsequent DevEUI_uplink messages.
Is that observation correct, and is this in fact behaviour as designed, or is it a bug?😅
Reputatie 6
Badge +6
Goodmorning,

Thank you so much for the observation!
This clarifies the situation even more and helps a lot. This is also very usefull for other LoRA users.
As I look to your example I completely agree that it is strange that there is no DevEUI_location message send after the uplink message at 06:00. And it is even more strange that the uplink message from 08:00 refers to to an 06:00 position update! I'll put this through to the specialists, so they can look into it. I'm expecting this is a bug, but off course we need to be sure!
Reputatie 6
Badge +6
Hi @rharte,

Can you please send me the DevEUI of the device which you used for above example?

You can send this in a private message.
Beste KPN,

Alvast bedankt voor het activeren van geolocation op de Developer portal!
Ik ben aan het testen met ADP en OTAA op dezelfde LoRa mote (maar dan met aangepaste firmware), en verstuur per minuut een pakketje van 42 bytes met ADR.

Er zijn mij een tweetal zaken opgevallen:
1) Gebruik makende van ADP krijg ik niet, zoals verwacht, een 'DevEUI_uplink' optioneel gevolgd door een 'DevEUI_location'. maar vaak alleen een 'DevEUI_location' en af en toe een 'DevEUI_uplink'. Dus ik mis de payload data heel vaak...
2) Gebruik makende van OTAA krijg ik na het versturen van zo'n 6 uplinks (dus na 6 minuten) error-meldingen van mijn mote en kan vervolgens uren geen uplinks versturen (ik gebruik de Sodaq One V2 met retries geactiveerd). Dit gebeurt zowel bij Developer als Thingpark en alleen met de OTAA. Lijkt erop dat KPN iets controleert en vervolgens blokkeert. Klopt dit?
Reputatie 6
Badge +6
Goedemiddag @Kees DPD,

Wat goed om te lezen dat u gelijk bent gaan testen met Geolocation!
Natuurlijk help ik u graag en zoek ik graag uit hoe dit precies kan. Ik moet eerlijk zeggen dat ik het antwoord voor punt 1 verschuldigd moet blijven. Dit leg ik voor aan de specialisten om hier duidelijkheid in te krijgen.

Wat betreft punt 2 vermoed ik dat u inderdaad tijdelijk geblokkeerd wordt omdat u het limiet van aantal berichten overschrijdt. Op de Developer Portal is het in ieder geval zo dat u maximaal 3 berichten per uur mag versturen. Voor ThingPark werken we met een duty cycle die het limiet bepaald. Ik weet alleen niet precies voor hoelang de blokkade geldt. Ook dit leg ik natuurlijk gelijk voor aan de specialisten. Zodra ik antwoord heb geef ik natuurlijk direct een gil, Vermoedelijk wordt dit begin volgende week.

Ik wens u in ieder geval alvast een fijn weekend!

Reageer