Sticky

LoRa | Geolocation

  • 4 november 2016
  • 59 reacties
  • 10796 keer bekeken

Reputatie 7
Badge +11
  • KPN Medewerker
  • 3505 reacties
LoRa enables customers to use geolocation to track the position of your LoRa assets. KPN is one of the first providers to offer operational geolocation with LoRa.
This topic is about how to use geolocation with Thingpark and the LoRa Developer Portal.

Geolocation by multilateration

All LoRaWAN devices use broadcasting to send their messages. This means that all gateways within reach will receive the message and our core-servers will figure out what the message is and collect all received signals. One benefit of this approach is the ability to triangulate (or multilaterate) the location of the device when three or more gateways receive the broadcasted signal. Each gateway will receive the signal at a different point in time, depending on the distance between gateway and device. Note that the differences in time between gateways will be on the nanosecond scale, since the signal travels with the speed of light. From the time differences our core server can calculate the location of these gateways and forward the result to the application server. Note that no extra payload or signal needs to be broadcasted by the device. The beauty of geolocation in LoRaWAN is that there is no need for expensive chips or complicated payloads on the device side. The only thing needed is to instruct our Thingpark core to apply the triangulation calculation for a device.

Structure Geolocation in Thingpark

A connectivity plan can be configured for API messages to include geo-location information. Right now, this cannot be done automatically, but has to be done manually by our supplier. Selected customers can give us a limited number of DevEUIs which we will ask to be configured correctly.

When configured correctly, the usual API messages containing payload (DevEUI_uplink) will contain extra fields that say something about the location. An example can be found here. This will contain the following elements:

DevLocTime Timestamp of when the location was calculated. This can be significantly different from the timestamp of the payload
DevLAT Device Latitude in decimal degrees (see this wikipage for the different formats)
DevLON Device Longitude in decimal degrees
DevAlt This is not used yet, ignore for now
DevAcc This is not used yet, ignore for now
DevLocRadius This is not used yet, ignore for now
DevAltRadius This is not used yet, ignore for now

Asynchronous location messages

The API messages containing payload include the location as outlined above, but the timestamp of the location information can differ significantly, depending on the device uplink frequency. I.e. when sending once every half hour, the payload of the message will be forwarded directly, but location calculation can take some time and only be included in the next message 30 minutes later. To have access to location information as soon as possible a new type of message is introduced by Thingpark. This DevEUI_location only contains location information and is send separately. An example can be found here. It contains the same elements as outlined above. Note that the security token for this message is calculated in a different way, which will be added here later.

Provisions for geolocation testing

• The API message format will likely change in upcoming releases, so expect to change the parsing in your application server at a later time.
• KPN cannot guarantee availability or accuracy of the location functionality in this testing phase
• As always, devices have to obey the duty-cycle
• ADR is best kept on for static devices

There are two types of localisation messages, DevEUI_uplink and DevEUI_localisation. The first one is for the payload where the last known location is added to (independant of the time that has since past). Additionally, there is the DevEUI_localisation that is sent at the moment a location is being calculated. Below, you can find a link to examples of the JSON-bodies of both messages.

DevEUI_uplink
DevEUI_location

Where can I test Lora Geolocation?

KPN will offer nationwide outdoor LoRa Geolocation in the Netherlands. The Geolocation functionality is currently enabled on all gateways in the Netherlands (exceptions further down this guide). There are many locations and areas in the Netherlands at which the Geolocation function can be tested. The coverage and functioning of Lora Geolocation will keep improving while we make progress with the deployment of the network.

Accuracy of KPN Lora Geolocation

As tdoa (time difference of arrival) is the principle used for calculating the position of the LoRa device, environmental factors can cause reflections which impact the service. On average in the Netherlands in 90% of the uplinks a successful position is calculated. In 95% percent of those cases the accuracy is below 100 meters. Again, those results can only be expected for nonmoving objects.

Using LoRa Geolocation - Applications

Lora Geolocation can be used for all outdoor applications. In the current state it is important to know that the Geolocation improves as more messages are sent from the same location. Especially when you are using moving devices, we recommend that you take this into account.

Settings to optimize testing in Thingpark

For testing, we make use of a special connectivity plan that has been optimized for LORA Geolocation. This connectivity plan uses forced ADR and the antenna diversity setting is 3. In addition, we recommend to switch-on ADR for the devices that are used for Geolocation.

Geolocation in the LoRa Developer Portal

To enable developers to test their application using the KPN LoRa network and its geolocation functionality, the feature has been added to the Developer Portal. Users can choose to enable geolocation per device when adding a device.

By default you will receive the geolocation information in the DevEUI_uplink message you get from the developer portal as described under “Structure Geolocation in Thingpark”. Per device you can enable the asynchronous DevEUI_location messages as described under “Asynchronous location messages”. You can do this by choosing “yes” for “Enable GeoLocation” when editing your device:


Useful links

- LoRa: Starters Guide
- LoRa: Forum and Manuals
- LoRa: Dictionary & Definitions
- FAQ: Frequently Asked Questions
- Tools: www.LoRaTools.nl

59 reacties

Reputatie 6
Badge +6
Hi @tonb,

Leuk om u weer terug te zien!
Goed dat u deze vragen stelt. Geolocation is voor zowel de Developer Portal als Thingpark gelijk. Echter is er op het gebied van nauwkeurigheid wel een klein verschil. We maken namelijk onderscheid tussen 4 categorieën devices namelijk static, slow moving, fast moving en nomadic. Per categorie hebben we een eigen nauwkeurigheid.

Op de Developer Portal is ervoor gekozen om een static profiel in te stellen. Dit is niet te wijzigen en zorgt er dus ook voor dat de nauwkeurigheid van een static profiel te verwachten is via de Developer Portal. Op dit moment is de nauwkeurigheid bij dit profiel 60 meter met een succes rate van 90%.

Nu is het natuurlijk zo dat we een landelijk dekkend netwerk hebben, maar natuurlijk zal de dekking en dus ook de nauwkeurigheid niet op elke plek gelijk zijn. Ik heb echter geen zicht op de sterke en de zwakkere plekken in het netwerk.
Reputatie 1
Badge
Ik wil wat metingen doen naar de nauwkeurigheid van LoRa geolocation onder diverse omstandigheden. Is er nog een verschil in te verwachten nauwkeurigheid tussen de developer portal en het productie Thingspark?

Tweede vraag: zijn er plekken in Nederland waar de verwachte nauwkeurigheid "bovengemiddels hoog" is?
Reputatie 6
Badge +6
Hi @Corne van Strien,

Wij willen graag uw specifieke situatie verder onderzoeken om tot een verklaring en oplossing te komen.
Wilt u mij aub de DevEUI van het device dat u gebruikt sturen?

Dit kan eventueel in een privébericht als u het liever niet openbaar post.
Reputatie 6
Badge +6
Hi @Corne van Strien,

Welkom bij de IoT Community!
Ik ben nogmaals mijn conversatie met de specialisten in gedoken en ik zie dat we nog niet tot een specifieke verklaring en oplossing gekomen zijn. Ik heb daarom direct het verzoek uitgezet om hier nogmaals in te duiken. Ik hoop hier z.s.m. een antwoord op te hebben.
Hallo,

Is er al helderheid over het probleem zoals gemeld door 'Kees DPD':

"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... "

Ik ondervind hetzelfde issue, Super dat Geolocation nu ook in de developer portal beschikbaar is. Maar als je wel de locatie doorkrijgt maar niet de data dan is dat toch wat lastig 🙂.

Met vriendelijke groet, Corné
Reputatie 6
Badge +6
Goedemorgen @Kees DPD.

Bedankt voor uw reactie!
Er wordt geadviseerd om Geolocation alleen outdoor te gebruiken. Het blijft echter natuurlijk wel vreemd dat het Lelystad niet blijkt te werken. Ik maak daar zeker nog even een melding van bij de specialisten. Met de window van een uur wordt bedoeld dat er minimaal een uur tussen het versturen van berichten moet zitten.
Hallo @Rick S.

Alvast bedankt voor de informatie!
Ik lees inderdaad dat het mote interne timers gebruikt om de duty-cycle 'af te dwingen'. Ik begrijp dus dat iig KPN hier geen controle over uitoefent.
Het blijkt een bepaald gebied van Lelystad te zijn waar geen geolocation is. De mote werd zowel in- als outdoor gebruikt, en hiermee werden dus wel uplinks verkregen.
Het verhaal over het schuivend window begrijp ik niet. U wilt hiermee zeggen dat als het mote 1 x per uur contact maakt, de geolocation van de vorige max. een uur later verzonden wordt?

Gr.

Kees
Reputatie 6
Badge +6
Hi @Kees DPD,

Daar ben ik weer!
Inmiddels heb ik een terugkoppeling ontvangen op de vragen die ik uitgezet heb.
De terugkoppeling is als volgt:
  • In Thingpark is een schuivend window van 1 uur, dus als u om 13.15 uur iets heeft verstuurd, dan kan de volgende keer pas om 14.15 uur zijn
  • Het device heeft ook een interne duty cycle. Bent u hiervan op de hoogte?
  • M.b.t. Lelystad e.d., gebruikt u het device indoor of outdoor? In Lelystad zou namelijk gewoon Geolocatie moeten zijn.
Hallo Rick,

Dit leg ik voor aan de specialisten om hier duidelijkheid in te krijgen.

Als je ze toch gaat benaderen, ik heb een test rit gedaan met geolocation waarbij het volgende is opgevallen:
- Iig in Lelystad staat geolocation uit. Ik krijg alleen 'uplink's met daarin een niet veranderd ,"DevLocTime" (laatste bekende vaststelling van een geolocation?)
- In de buurt van Huizen en Meerkerk is de nauwkeurigheid van geolocation ruim 7 km! Ik vermoed dat ook hier geen geolocation kan worden bepaald en ipv de coordinaten van de ontvangende gateway doorgeeft?

Ik hoor het graag en ook prettig weekend!
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!
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
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.
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 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
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
@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 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 😉
@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,

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).
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.
@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 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?
@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 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?
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.

Reageer