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
