LoRa | Geolocation

  • 4 November 2016
  • 59 reacties
  • 14156 keer bekeken

Reputatie 7
Badge +11
  • Allesweter
  • 3490 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

Hi Michiel,

If i understand this correctly, then the location information is sent from the device itself (fields DevLat and DevLon) via the API message.

Do you know if geolocation by triangulation via the gateways on the roadmap? This would free up space on the payload and still deliver functional, correctly timed geolocation of the device.

Greetz,

Jeroen
Reputatie 2
Badge +1
Hi Michiel,

If i understand this correctly, then the location information is sent from the device itself (fields DevLat and DevLon) via the API message.

Do you know if geolocation by triangulation via the gateways on the roadmap? This would free up space on the payload and still deliver functional, correctly timed geolocation of the device.

Greetz,

Jeroen

Hi Jeroen,

No you do not understand this correctly 🙂. I see there is some confusion about this so I added a new paragraph "Geolocation by triangulation" to the TS. What I mean to say is that this is triangulation. The API message are added by the core server, not by the device. No extra effort on the device side is needed.

Does this make sense?

Michiel
Hi Michiel

Yes, it makes total sense. The IOT device can remain simple and the servers do the number crunching..

Would the system also be able to calculate height coordinates?

Regards,

Jeroen
Reputatie 7
Badge +11
Hi Jeroen,

The system isn't capable to calculate height coordinates yet. But it's a feature on the roadmap with no estimated time of arrival!
Hi,

- How can I be provisioned with geolocation tests?
- What is the latest planning on the geolocation availability in the production environment?

Best regards,
Bert
Hi,

Is my interpretation correct that I see contradiction statements in the opening post regarding ADR?
I read the following two statements:

1) 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.
2) Please use SF12 with ADR off for these test. Note that in the final solution, ADR has to be switched on!

Is statement 1) about the default setting for the device once geolocalisation is fully available and statement 2) for the testing phase you're currently in? So, for testing geolocalisation now, should ADR be switched off?

Best regards,
Bert
Hi,

Is my interpretation correct that I see contradiction statements in the opening post regarding ADR?
I read the following two statements:

1) 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.
2) Please use SF12 with ADR off for these test. Note that in the final solution, ADR has to be switched on!

Is statement 1) about the default setting for the device once geolocalisation is fully available and statement 2) for the testing phase you're currently in? So, for testing geolocalisation now, should ADR be switched off?

Best regards,
Bert


Hi all,

Through trial&error I've found out that the network must control the data rate when testing geolocalisation.

Best regards,
Bert
Reputatie 7
Badge +11
Hi all,

Through trial&error I've found out that the network must control the data rate when testing geolocalisation.

Best regards,
Bert
Thanks for sharing your findings Bert! 🙂
Reputatie 1
Badge
Hello

How can I test geo location fro the dev portal?

Cheers
Reputatie 7
Badge +11
Hello Amine,

Do you have a contact at KPN for LoRa? Geolocation is as far as I know not yet accessible. If you're interested I can get you in touch to get access. Tests are only available in a limited number of locations and only valid for stationary cases.
Reputatie 1
Badge
Hello Amine,

Do you have a contact at KPN for LoRa? Geolocation is as far as I know not yet accessible. If you're interested I can get you in touch to get access. Tests are only available in a limited number of locations and only valid for stationary cases.
Hi Tim. Please connect me with someone from KPN to test. Cheers!
Reputatie 7
Badge +11
Will do Amine, please check your PM inbox 🙂
Hi,

While looking through my LoRa Data I noticed the "LrnDevEui" of an uplink messages is in capital letters and the "LrnDevEui" of a location message is not. This caused some unexpected problems while sorting my data by "LrnDevEui".

Are you aware of this difference and is there any reason for it?

Thanks in advance, I hope this will be changed in the near future.

Jan
Reputatie 7
Badge +11
Hello @jankappe, we are currently looking into this problem. I'll post an update if we make any progress.
Reputatie 7
Badge +11
Hi @jankappe, can you share a JSON message with us? If possible, one normal, and one location type.
Hi @Tim,

Here is a location type message:

code:
{
"Token": "04cc6dbfe61991208d58b9537b66c263befbe48ef605150733eb506e5a0278e8",
"LrnFPort": "0",
"DevEUI_location": {
"DevAltRadius": "0.000000",
"DevEUI": "0059AC00001830C8",
"DevAddr": "15293375",
"DevLON": "5.411983",
"DevLAT": "51.479717",
"DevAcc": "0.000000",
"Time": "2017-03-31T12:24:49.0+02:00",
"NxGeolocAlgo": "0",
"NwGeolocTdoaOpt": "0",
"DevAlt": "0.000000",
"DevLocTime": "2017-03-31T12:24:49.0+02:00",
"DevLocRadius": "0.000000",
"CustomerID": "100006334",
"Lrcid": "0059AC01"
},
"timeReceived": "2017-03-31T10:24:49Z",
"Time": "2017-03-31T12:24:49.61+02:00",
"LrnInfos": "TWA_100006334.683.AS-1-33061",
"LrnDevEui": "0059ac00001830c8",
"AS_ID": "asidsalvo"
}


And here the normal one:

code:
{
"Token": "df0bee9e60bbfd47e3f527be1c3cf739351ce4bd223ee69688cba547722bc6a4",
"LrnFPort": "4",
"DevEUI_uplink": {
"AckRequested": "1",
"DevLrrCnt": "6",
"rawMacCommands": "",
"Late": "0",
"ADRbit": "1",
"LrrLON": "5.440173",
"payload_hex": "00346b3a03c814af1e9500480900000000",
"Channel": "LC7",
"FPort": "4",
"DevAddr": "15293375",
"CustomerData": {
"alr": {
"pro": "Nomadic",
"ver": "1"
}
},
"FCntDn": "11",
"CustomerID": "100006334",
"Lrcid": "0059AC01",
"LrrSNR": "0.000000",
"FCntUp": "11",
"mic_hex": "17a1e29c",
"MeanPER": "0.041866",
"Lrrid": "FF010328",
"DevEUI": "0059AC00001830C8",
"Time": "2017-03-31T12:24:48.314+02:00",
"ModelCfg": "0",
"LrrRSSI": "-111.000000",
"MType": "4",
"Lrrs": {
"Lrr": [{
"LrrSNR": "0.000000",
"Lrrid": "FF010328",
"LrrESP": "-114.010300",
"LrrRSSI": "-111.000000",
"Chain": "0"
}, {
"LrrSNR": "-12.000000",
"Lrrid": "FF010381",
"LrrESP": "-127.265724",
"LrrRSSI": "-115.000000",
"Chain": "0"
}, {
"LrrSNR": "-17.000000",
"Lrrid": "FF01047D",
"LrrESP": "-132.085800",
"LrrRSSI": "-115.000000",
"Chain": "0"
}]
},
"LrrLAT": "51.477493",
"SpFact": "12",
"InstantPER": "0.090909",
"SubBand": "G2"
},
"timeReceived": "2017-03-31T10:24:49Z",
"Time": "2017-03-31T12:24:49.60+02:00",
"LrnInfos": "TWA_100006334.683.AS-1-33058",
"LrnDevEui": "0059AC00001830C8",
"AS_ID": "asidsalvo"
}


I hope this will help!
Reputatie 7
Badge +11
Sorry for the delay @jankappe,

Thanks for sharing! I've forwarded your message to my colleagues. Hope we'll find the cause soon, I'll let you know. 🙂
Reputatie 7
Badge +11
Hi @jankappe,

We cannot reproduce this! I have fetched the JSON message trough the developer portal, but if I send the message in uppercase letters, it will look like this again. The message is not changed on the way.
Therefore we think the problem should be found within your application server.
Hi @Tim,

Strange! I will look into it. Thanks for your time.

Jan
Reputatie 7
Badge +11
No problem! Hope you find out what is causing this, please share your findings on the forum 🙂
Hi Tim,

Could you help me get in touch with a KPN contact to get access and test Geolocation?

Many thanks

Gertjan
Reputatie 7
Badge +11
Hi Tim,

Could you help me get in touch with a KPN contact to get access and test Geolocation?

Many thanks

Gertjan

Sure! Can you sent me a PM with your DevEUI?
"Tests are only available in a limited number of locations and only valid for stationary cases. Moving objects are not supported yet."

Can someone explain if this is still the case ? Why are moving objects not supported ? Any details ?

Thanks!
Reputatie 1
Badge

Why are moving objects not supported ?


Accuracy of the fine timestamps which are used for LoRa TDoA positioning is disappointing, and multipath propagation brings even more troubles. So you need a (huge) number of messages to feed the filter/solver with their ts and other metadata to get not-too-disasterous positioning accuracy.

Actually, that's why Actility had gave up and bought Abeeway which provides assisted GPS solutions.

Why are moving objects not supported ?


Accuracy of the fine timestamps which are used for LoRa TDoA positioning is disappointing, and multipath propagation brings even more troubles. So you need a (huge) number of messages to feed the filter/solver with their ts and other metadata to get not-too-disasterous positioning accuracy.

Actually, that's why Actility had gave up and bought Abeeway which provides assisted GPS solutions.

Thanks for your reply!
Some more questions arised...
-Is this filter already implemented ?
-Is each calculated loacation indpendendly calculated from the timestamps? Or does it take into account previous locations?
-Are there algorithms implemented which assume the node is non moving ?
-What would be the best way to have location updates for moving objects ? Send 'frequently' on SF11 ?

Thanks!

Reageer