- DevEUI - Unique LoRa device identifier.
- AppEUI - LoRa application identifier.
- AppKey - LoRa device authentication and encryption root key.
This tab shows you detailed information about the messages send to and from your Device from the perspective of our LoRa network.
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:
- 1.The type of LoRa message.
- 1.Whether it was an uplink (🔵 blue) or downlink (🟢 green) message.
- 2.Whether it was a Join request, Join accept or regular message.
- 3.Whether the message was confirmed or unconfirmed, or whether the message carried an ACK.
- 4.Whether the messages contained data, mac, or both.
- 3.The exact timestamp of the message, with millisecond accuracy.
- 4.The frame counter value of the message. Uplink (FCntUp) and downlink (FcntDown) communication has its own counter.
- 5.An indication of the signal strength the message.
- 6.Click on the chevron at the end of a row to see more details of a message.
- 7.Search bar to see the message history up to a certain point in time.
- 8.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:
- 1.Details about the message signal:
- 1.The used Spreading factor.
- 2.The used LoRa channel.
- 3.The number of gateways that received the message (uplink only).
- 4.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.
- 5.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.
- 6.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.
- 2.Details about the content of the message:
- 1.The LoRa application port on which data was send or received (if applicable).
- 2.The exact payload of the LoRa message (if applicable).
- 3.The exact MAC content of the LoRa message (if applicable).
- 4.Flags that were in the LoRa message, like
- 3.Details of the LoRa Geolocation result:
- 1.Coordinates of the calculated location.
- 2.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.
Your LoRa data history should look like this when the join request is sent.
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.
Your LoRa data history should look like this when the join accept has been sent.
After your Device has received and processed the join accept, it can begin sending data.
Your LoRa data history will look this way after your Device has sent its first uplink.
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.
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.
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.