LoRa is one of the main communication technology used in today’s Internet of Things. It allows long range transmission for low power devices. The most common way of using LoRa is through the LoRaWan protocol: A standard protocol aimed at connecting LoRa devices to the Internet via gateways.
LoWAPP, which stands for LoRa Wide Area Peer Protocol, is a LoWPAN type protocol that uses LoRa as its physical transmission layer. It is a preamble sampling network protocol, aimed at peer-to-peer communication, with no mesh capabilities.
Our use case
A few months ago, a customer came to us asking for way to allow their workers to communicate with each other in restrained environment, like deep in the mountains or in underground tunnels. Using standard GSM was not possible, as these areas usually don’t have great 3G or even 2G coverage.
Using LoRa devices with the standard LoRaWan protocol was not possible either as it would require to install gateways through all those areas. That’s where we proposed to develop a peer-to-peer network protocol for LoRa, that would allow LoRa devices to directly communicate with each other without depending on any type of existing network infrastructure.
As a preamble based protocol, each data transmission is preceded by a long preamble. Each device listens for a short time (with a Channel Activity Detection – CAD) at a regular interval equivalent to the duration of the preamble. If a preamble is detected, the devices starts listening for the message. Using a preamble based approach allow for a (relatively) energy efficient protocol.
A specification document was written in the first half of 2016, describing the format of the frames transmitted, the workflow of the protocol (through a state machine), as well as the interface that would allow a user or an application to communicate through it (using AT modem like commands).
Simulate, test and implement
The core of the protocol is designed to be portable. All interactions between the hardware platform and the core is done through a series of system functions sent to the core at initialization. This modular approach enabled us to first build a simulated environment for LoWAPP before working on our hardware boards.
The simulation is a multi-threaded Linux C program. The following table shows the equivalence between the simulation and the hardware implementation:
|Architecture||Linux process||STM32 MCU|
|Storing device configuration in persistent memory||Text files||EEPROM|
|Communication between devices||Frequency specific text files||Semtech SX1272 radio chip|
|Interaction with an app or user||Console I/O||UART|
|Timing functionality||Linux time.h and rt librairy||Logic timers managed by an RTC|
Running the protocol first in a simulation had several advantages. It allowed us to validate the workflow of the protocol, and detect potential issues in the specifications. The simulation also allowed us to test limit case with a high density of devices or a high frequency of transmission requests. Once the simulation was working, we could easily setup a series of tests using scripts that launched the simulation program several times and sent to each device different commands to execute. Another benefit was the ability to easily debug a network of several devices. It was especially interesting to be able to see exactly when and what was transmitted on the fake radio.
The simulation also enabled us to get precise timed logs of all activity done by each tag (on the same time basis), allowing for extraction and analysis of data like success transmission rate, error type analysis or active/sleep time ratio…
After validation of the LoWAPP core in simulation, we started working on the hardware implementation. Our board uses a STM32L1 microcontroller with integrated EEPROM as well as a Semtech SX1272 LoRa chip.
Another benefit was the ability to easily debug a network of several devices
We started the project from a Semtech example project that already contained all the device specific initialization, the radio driver, as well as an abstraction layer on top of the STM32 HAL. Integrating the LoWAPP core into this project meant that we had to write all the system functions required to initialise the core, using the Semtech abstraction layer and the SX1272 drivers. A few things had to be modified in the core itself, especially regarding the prototypes of some of those system function, to better match was the actual radio does.