LoRa devices
Last updated
Last updated
Devices with LoRa connectivity have some specific tabs on the Device detail page to display LoRa specific information.
Currently only LoRaWAN 1.0.x is supported. Also, only OTAA is available. ABP is not available since it is less secure.
DevEUI - Unique LoRa device identifier.
AppEUI - LoRa application identifier.
AppKey - LoRa device authentication and encryption root key.
Learn more about LoRa connectivity in KPN Things.
This tab shows you detailed information about the messages send to and from your Device from the perspective of our LoRa network.
Messages in LoRa data history are stored up to 1 month.
The message overview of LoRa data history gives you an overview of all message to and from your Device in descending order of time. So the most recent message is at the top of the list of messages.
What you can see here is:
The type of LoRa message.
Whether it was an uplink (🔵 blue) or downlink (🟢 green) message.
Whether it was a Join request, Join accept or regular message.
Whether the message was confirmed or unconfirmed, or whether the message carried an ACK.
Whether the messages contained data, mac, or both.
Whether a LoRa Geolocation result could be determined on that message (only available for uplink).
The exact timestamp of the message, with millisecond accuracy.
The frame counter value of the message. Uplink (FCntUp) and downlink (FcntDown) communication has its own counter.
An indication of the signal strength the message.
Click on the chevron at the end of a row to see more details of a message.
Search bar to see the message history up to a certain point in time.
Button to load more data history (if available).
When you open the details of a message by clicking the chevron at the right side of the row, you can see the following:
Details about the message signal:
The used Spreading factor.
The used LoRa channel.
The number of gateways that received the message (uplink only).
The Received Signal Strength Indicator (RSSI) of the message (uplink only). This gives you an indication of how strong the message's signal has been received by the best receiving gateway.
The Signal to Noise Ratio (SNR) of the message (uplink only). This gives you an indication of the amount of noise when the message was received by the best receiving gateway.
The Estimated Signal Power (ESP) of the message (uplink only). ESP is calculated from RSSI and SNR and gives an indication of the used link budget.
Details about the content of the message:
The LoRa application port on which data was send or received (if applicable).
The exact payload of the LoRa message (if applicable).
The exact MAC content of the LoRa message (if applicable).
Flags that were in the LoRa message, like ACK, FPending or ADRAckReq.
Details of the LoRa Geolocation result:
Coordinates of the calculated location.
Radius in meters, the theoretical inaccuracy of the LoRa Geolocation result.
This section will explain what you can expect when you first connect your LoRa Device to KPN Things.
In the screenshot below you can see the beginning of a typical LoRa data history. The message are shown in descending order of time, so the first message is at the bottom of the list of messages.
Below at the section Step 5. Normal operation you can find an even more elaborate example. If your LoRa data history is not the same as in the screenshot above, you can continue reading to understand the chronology of LoRa data history.
The first thing your device should do is try to join our network. With a join request, the device will ask to network whether it may join. Learn more about joining in LoRaWAN.
This means the network does not see any activity from your device. Try one of the following actions to fix:
Check whether the LoRa registration was successful by checking the connectivity status on the Device detail page.
Check if your device is programmed/configured with the same DevEUI you find in the connectivity details on the Device detail page.
Check if your device is sending the join request on one of the default LoRaWAN channels. Learn more about LoRaWAN channels.
Maybe the network coverage is not ideal at your current position. Thick walls or a sub-optimal antenne can cause issues. Try to move to a more exposed location for better coverage, like moving closer to a window.
It could be that your device is not sending the join request on SF12, the spreading factor with the farthest reach. Program/configure your device to use this spreading factor when joining to increase coverage of your device.
Maybe you are completely out of reach of the network. You can check our LoRa network coverage online.
After receiving the join request, the network will check whether the Device is known and whether the security details are correct. If so, the network will respond with a join accept.
This means the network sees your requests to join the network, but there is a (security) reason not to accept your join request. Try the following to fix it:
Check if your device is programmed/configured with the correct AppEUI.
Check if your device is configured with the correct AppKey. This could also have to do with the endianness with which you should enter the AppKey in your device.
Try to remove your device from the Portal and re-add it, maybe you made a typo when registering your device.
After your Device has received and processed the join accept, it can begin sending data.
This means the join is completed from the network point of view, but somehow your device does not see it the same way. Try the following to fix it:
Often join accepts are sent on the RX2 receive window. Is your RX2 receive window correctly configured? This should be 869525000 MHz and DR0 (SF12). Some device manufacturers have the device wrongly configured with the RX2 receive window listening on DR3 (SF9). (This is a common issue with Dragino devices!)
Sometimes the link budget for downlink is smaller than uplink, meaning downlinks are harder to receive than it is to send uplinks. This accounts for worse coverage for downlink than for uplink. Try to move to a more exposed location and try again.
It could be that there is a programming error in your Device that causes your Device to incorrectly process the Join accept. Please refer to your device manufacturer documentation for more help on that.
It could be a LoRa reception problem, due to configuration problems or insufficient coverage. You can check the possible solutions for "I don't see uplink data appearing in the LoRa data history!" above for more info.
Download messages are messages send by the network to your Device. These can be mac messages, containing commands to your Device about LoRaWAN transmission settings, or they can contain data from your application or from KPN Things.
After a Device has joined, the network will send up to three downlink messages with mac commands in them.
Now your Device will go into normal operation, often meaning periodically sending uplink messages. In the screenshot below you can see a typical LoRa data history.
Using the timestamps for consecutive uplink messages you can determine the average sending interval of your Device. This sending interval should not be too high, since you might be violating the fair use policy of KPN Things.
Make sure your Device does not send more often than once every 5 minutes on average.
Each mac command consists of a request and an acknowledge message. So mac messages should come in pares in the LoRa data history.
If this is often not the case and you see that downlink mac messages are not answered by the Device, please check your Device, because there might something wrong. If your Device does not follow up mac commands, the transmission settings cannot be optimized.
Make sure your Device responds to all mac commands.
Not every uplink message will give a new calculated LoRa Geolocation. This is normal. It can be caused by the fact that too few gateways received the uplink, or if other circumstances were sub-optimal.
When a value for FCntUp is missing in the LoRa data history, it means that that specific message has not been received by the network. In LoRaWAN communication it is normal to have lost messages, your application should take this into account. It is a side-effect of the very energy efficient way LoRaWAN works. In normal situations you can expect up to 5% message loss. If your losses are higher, coverage on the location of your Device might be temperate.
If you see a join ceremony before each first message (FCntUp = 0), there is something wrong with your Device. Maybe it is losing power in between data transmissions or there is another reason your Device rejoins after each message.
Your Device should not rejoin after each message, because it puts unnecessary stress on the battery consumption of your device and it prevents the network to optimize the LoRaWAN transmission configuration through mac commands.
Make sure your Device remembers its join in between uplink messages.
If you see your Device (almost) only send Confirmed uplink messages, your Device is not properly configured. Sending too much Confirmed uplink messages puts too much demand on downlink communication, since every Confirmed uplink message requests a downlink message containing an ACK (acknowledgement) from the network. The network has not been designed to handle constant Confirmed uplink messages. This will negatively impact the overall capacity of the network. Therefor the use of Confirmed uplink messages is part of our Terms of Use.
No more than 10% of the uplink messages of your Device may be Confirmed messages. All other messages must be Unconfirmed.
Want to learn more about LoRa connectivity? Head on over to our KPN LoRa documentation!
