LoRaWAN Communication
The LoRaWAN Communication within this device is based on the iQ LoRaWAN Stack Version 2.1.0
General
The LoRaWAN Interface is in compliance with the LoRa Alliance specifications, and is based on the LoRa transmission standards.
Using the LoRa protocol the device can reliably transmit data over large distances without permanent communication.
The interface constantly adapts to the optimal transmit and receive parameters individually to ensure a stable and reliable link to the LoRaWAN Gateway.
The status of the link to the LoRaWAN network is shown on the device’s display.
The LoRaWAN interface is compatible with LoRaWAN V1.0.4.
Battery Powered Devices are configured as Class A devices while mains powered devices are configured as Class C device.
The required parameters and configuration of the LoRaWAN interface are permanently saved inside the device.
All devices are delivered with OTAA mode enabled, the DevEUI of the device is listed on the package and on the device itself.
Infrastructure
IoT System Components
The Customer is responsible for a working LoRaWAN Infrastructure, a typical LoRaWAN infrastructure consists out of;
Node / Device : a device that is equipped with a wireless communication module which forms the payload to send to a gateway or receive data from a gateway.
Gateway : a device that can be seen as a router, equipped with a LoRa concentrator, that receives the LoRa packets and send them on their way to a network server / platform.
Server Platform : a platform that is usually cloud based where all communication is being prepared and processed. The processing can either be done on the platform where it's being stored, analysed and presented or it can be forwarded to an IoT Platform that handles these actions.
If needed YOBIIQ can support customer with the selection and configuration of the infrastructure, this however is not covered by the normal support coverage.
YOBIIQ also supplies a turn-key LoRaWAN Infrastructure if customer has no experience with the required infrastructure.
Operational Procedure
JOIN Process
Start-up of the product, JOIN process and configuration
The product start the JOIN process within the product start-up process.
As long as the device is not connected to a LoRaWAN network, the interface regularly tries to connect to a LoRaWAN network.
These Join requests occur randomly in a ~10 min time period to counteract bandwidth problems if multiple devices are in the same network
Rejoins
If the device detects that it has not received confirmation after 5 consecutive uplink transmissions it will send 3 LinkCheckReq packets to the network server to validate connectivity. In the event that no confirmed uplinks are being used by the device, every 24 hours the device will send 3 LinkCheckReq packets to the network server to validate connectivity.
If there is no response to the LinkCheckReq packets the device will initiate a rejoin to the network.
The LoRa Communication Watchdog alarm will trigger when the LinkCheckReq packets are not responded to.
The LoRa Uplinks, Rejoins and Communication Watchdog Alarms are logged on the device with a timestamp.
Network Quality Test
During the JOIN Process, the device will perform a network quality test. When the test is running the device shows this by utilizing the LED on the device.
A device configured in Class C will perform the network test during a Rejoin Request as well.
The result of the test is given by the devices after around 20 seconds following the Join Accept. It is visible by utilizing the LED on the device.
With this information the installer knows the quality of the network and can move the device to a place with a better coverage.
Good
SF7 or SF8
Medium
Other SF factor with a link margin > 6
Bad
Other SF factor with a link margin <=6
Time synchronization
The device performs a time synchronization during normal operation, it performs this at least once every 24 hours.
The device will adjust its internal clock to match with the time returned by the time synchronization.
Sending measurement registers
The device sends all requested measurements directly from its datalogger via LoRaWAN without any changes to the data.
The requested measurements are read from the data logger at the due date of the interval.
Example of a transmission interval of 15 minutes:
10:00:10am: The LoRaWAN communication module reads out the latest data logger entry. The values stored there are from 10:00:00am.
10:00:11am 10:14:59am: The device tries to transmit the data via the LoRaWAN network.
Notes on the transmission of measurements;
Be aware that, if you operate multiple devices in the same LoRaWAN network, transmissions by these meters may collide. The device will however adjust its transmit parameters to ensure smooth transmissions.
Please make sure that both the device and the LoRaWAN network are configured in such a way that the device can transmit its full package to avoid losing data in failed transmissions.
Data Retransmission
Internal:
Data Retransmission will only be available on devices that have additional SPI Flash.
The device supports the retransmission of data to ensure that all available data is submitted to the network server and overcome downtimes of the LoRaWAN network.
If enabled the data retransmission is triggered by failure of the LinkCheckReq, once triggered the device will record the timestamp of the failure and store the uplinks in a buffer. If the LinkCheckReq packets are getting a response the device will re-transmit all the data that has been logged into the buffer since the failure.
The amount of data you can save into the buffer depends on the type of device, the buffer operates on a FiFo method meaning that once the buffer reaches it's maximum size it will replace the oldest entry in the buffer.
When the Data Retransmission is utilized it can lead to an increased amount of uplinks and shorten the battery life of a device.
Last updated