Learning LoRaWAN Basics
Repeating the IoTUK Boost workshop and looking at LoRaWAN in further detail.
In the post Diary of a Trainee Electronics Engineer: May 2017 I mentioned that I attended a LoRaWAN workshop for Calderdale IoTUK Boost programme participants, and gained a basic understanding. Initially the differences between LPWAN, LoRa and LoRaWAN weren’t clear to me, however, after some reading I managed to understand the relationship between the three.
LoRaWAN network architecture is laid out in a star-of-stars topology where gateways act as bridges relaying messages between end-devices and the central network server. The gateways are connected to the server via standard IP connections and the end-devices use wireless communication to one or more gateways.
Image source: www.microchip.com
Communication between end-devices and gateways is spread over a range of frequency channels and data rates — LoRaWAN data rates range from 0.3 kbps to 50 kbps. Selecting the data rate is often a trade-off between message duration and communication range.
In order to achieve secure communication over the IoT several layers of encryption have been added, these are provided via:
- Unique Network key
- Unique Application key
- Device specific key
What I didn’t really look at in May’s diary post is the that LoRaWAN has several different classes of end-point devices to address the different needs reflected in the wide range of applications.
End-devices in Class A support bi-directional communication between a device and a gateway. This operation is the lowest power end-device system, for applications which only require downlink communication from the server shortly after the end-device has sent an uplink transmission. Here Uplink messages can be sent at any time, the device then opens two receive windows at specified times after an uplink transmission. If the server does not respond in either of these receive windows, the next opportunity will be after the next uplink transmission from the device. The server can respond in either the first or second https://wiki.thingscalderdale.com/LoRaWAN_Dev_Kit receive windows, the transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol). All of the examples from the LoRaWAN workshop come under this class.
The end-devices in class B are bi-directional with scheduled receive slots. This class is similar to Class A, however, Class B devices open extra receive windows at scheduled times in addition to Class A’s random receive windows. In order for the end-device to open its receive window at the scheduled time it receives a time synchronized beacon from the gateway, allowing the server to know when the end-device is listening.
Class C end-devices are bi-directional with maximal receive slots. This means that Class C end-devices almost have continuously open receive windows, which are only closed when transmitting. This allows for low-latency communication but is many times more energy consuming than devices in Class A. Due to the amount of energy required to keep a node actively awake running the receiver at all times Class C end-devices are used primarily for AC-powered applications.
LoRaWAN Development Kit
Each delegate at the workshop received a LoRaWAN development kit which contained:
- Adafruit 1.8” TFT Display
- SmartEverything LION board
- Pycom LoPy
- Pycom LoPy Expansion Board
In addition to relevant power supplies/programming cables, board housing, antennas and prototyping materials.
A full bill of materials for the LoRaWAN Development Kits can be found on the Things Calderdale wiki.
Here we’ll take a look at some of the examples from the workshop and what they’re doing.
Before delving straight in with the examples an up to date version of the Arduino IDE needs to be installed along with all the relevant board support and libraries. The SAMD and Arrow boards need adding support for, this can be done via the boards manager in the Arduino IDE.
Installing the relevant sensor and display libraries can also be added using the IDE via the libraries manager. Below are all the libraries which are required in order to participate in the workshop examples.
- SmartEverything SE868-AS
- Adafruit GFX Library
- SmartEverything Lion RN2483
- Adafruit ST7735 Library
The Things Network
The next thing to do is create a The Things Network account so you can begin creating applications and adding devices to them. Once you have created an account you need to create an application to get started — be sure to take note of the application EUI generated by TTN.
Next a device needs to be added to the application, however, before we can do this we need to determine the device EUI. To do this I used a sketch called getChipinFormation, this sketch allows us to determine the device EUI of the SmartEverything LION board and displays this in the serial monitor. With this information we can now register the device to the application and generate the application key.
Now that we have the Device EUI, Application EUI and Application Key we can include these in a sketch used to complete a basic network uplink. Using the example sketch sendDataOTA_console I entered the App EUI and App Key where this previously had either 0’s or x’s. Following which I uploaded the sketch and opened the serial monitor to see if the device had been accepted or denied to join the LoRaWAN network — if you have been accepted the message “Rx> accepted” should be displayed. If you receive the message “Rx> denied” this means you have been unsuccessful in joining the network. If this is the case check the App Key and App EUI have been entered correctly and try again.
When successfully connected under the device application data on TTN you should be able to see a payload of hexadecimal data, which can be changed to display a more meaningful format by altering the payload format.
Here we can see that the device is connected and is showing data on TTN for basic uplink. Next we can look at adding a sensor and using uplink to send readings from the sensor to TTN.
Next I wired up a DS18B20 temperature sensor to the SmartEverything LION, using the sketch OTA_Temperature — this takes temperature readings and then sends these up to the network.
To connect the DS18B20 to the SmartEverything LION we wire this up like so:
DS18B20 Pin 1 - GND
DS18B20 Pin 2 - D4
DS18B20 Pin 3 - VCC
DS18B20 Pin 3 - VCC via a 4k7 pull up resistor.
Once the sketch has been uploaded and has been accepted to join the network you should see data in the payload in the device application data on TTN. This will display in hexadecimal instead of degrees Celsius until the payload format has been updated. To change the interval between uplinks the time period can be altered in the sketch.
As I mentioned in May’s Diary post another example included uses downlink, which is the exact opposite of uplink as this involves sending data from the network down to a thing. Here we’re going to look at using downlink to control the on-board LED of the SmaryEverything LION via TTN.
In order to do this the App EUI and App Key needs to first be changed in the sketch OTA_DownlinkLED. Once these have been changed and the sketch has been uploaded we can use payload in the Downlink section of TTN to either turn off or on the on-board LED using either 00 or 01 respectively.
Here we can see using a payload of 01 illuminating the on-board led of the SmartEverything LION.
Using the Adafruit TFT module we can use downlink to display messages to the screen. Like we did previously we use the downlink payload section to determine what will be displayed on screen, however, this needs to be in hexadecimal for this to be displayed in ASCII on the screen. Using an ASCII converter enter the text you want to display and be sure to select convert white space characters and remove 0x when converting this to Hex.
Update the App Key and App EUI in the sketch and upload this. Once this is available in TTN update the downlink payload with the Hex. For the screen to display “Hello World!” the Hex would be 48656c6c6f20576f726c6421 with white space characters converted and the 0x removed.
Here we can see the Hex Data followed by the ASCII message “Hello World!” displayed to the screen.
While these examples of using uplink and downlink are relativity easy, I’m still at the point where if something goes wrong I’m not completely sure what to do. I’m looking forward to familiarising myself with LoRaWAN and The Things Network more so that I can understand how to add different peripherals and debug any errors I come across.
If anyone would like to have a go at the workshop themselves, you can find the LoRaWAN Development Kit bill of materials and workshop notes on the Things Calderdale wiki.