LoRaWAN on an ATMega328P using NiceRF RF LoRa modules

Here at Solarpunk we’ve been busy finishing the firmware of our POD board. Although we use LoRa point-to-point to communicate between our PODs, we wanted to test if we could communicate with our server via LoRaWAN, without making changes in hardware or switching software compiler.

Objectives of this post

Can we produce a device operating via LoRaWAN protocol using RF modules from NiceRF (with SX1262 microchip) with an ATMega328P MCU based board and using Arduino IDE as the compiler?

TL;DR

• Currently there are no libraries compilable with Arduino IDE that support the SX1262 radio module and fits inside an ATMega328P microchip memory.
• The simplest alternative for us was to “downgrade” the LoRa module to a SX1276 using the Arduino-LMIC library. This worked to produce a Class A LoRaWAN device that uses 64% of available flash memory (just for the communication, and excluding all other programming we want to implement).

First of all, why LoRaWAN?

Before going into our experiment, just a brief explanation of what LoRaWAN is and why it matters:

LoRaWAN is a wireless communication protocol built on top of Semtech’s LPWA modulation technique and hardware family called LoRa, that enables long-range, low-power communication between devices and the internet, making it ideal for a wide range of applications in various industries.

LPWAN stands for Low-Power Wide-Area Network, and the reason why it’s relevant even in a time were we have WiFi Mesh technology is because it enables a much wider coverage (due to the usage of lower frequency bands like 868MHz in Europe), at a much lower power usage (also due to the radio frequency operating bands), sacrificing data transmission rates, meaning that it is not good for video / audio transmission for instance. Therefore, it is designed for devices that require low data rates, long battery life, and long-range communication capabilities, like IoT (Internet of Things) applications.

There’s plenty of LPWA network protocols like LoRaWAN, NB-IoT, and Sigfox, but we prefer LoRaWAN since it has a big community and extensive support, is partially open sourced (LoRa technology and chips are patented by Semtech), and enables community networks like TTN and Helium. 

Diving into our experiment…

Going from point-to-point communication to LoRaWAN required us to reprogram our POD’s MCU with some new firmware. The main goal was implementing this without changing our board design and previous choice of firmware/hardware which consists in:  

– RF module: G-NiceRF LoRa1262-868, using the newer Semtech’s SX1262 transceiver (good combination of price, CE compliance, power consumption, availability within EU)

– MCU: ATMega328P (good combination of price, development platform, community support & low-power mode)

– RadioLib firmware as the library to communicate via LoRa

At the time of writing, RadioLib does not support LoRaWAN protocol. There is however mention that the development is ongoing, but stalled. You can follow that conversation here.

These were the alternative libraries that our research produced which could potentially implement LoRaWAN on a ATMega328P, but unfortunately for one reason or another none of them worked for us:

Arduino-LoraWan-LMIC-Library (doesn’t support SX1262)

Beelan-LoRaWAN (doesn’t support SX1262)

MKRWAN (only works for specific arduinos, like the NANO IOT)

Arduino LoRa (doesn’t support SX1262)

MCCI Arduino LoRaWAN Library (might work in conjunction with other libraries to handle the SX1262 radio)

Arduino-LMIC (doesn’t support SX1262)

RadioHead (only supports RFM95 chip)

SX126x (might work as library just for handling the SX1262 and using other library for handling LoRaWAN)

LMICPP-Arduino (could theoretically work but would require changing compiler)

BasicMAC (supports SX126X family but too big for ATMega328P)

The SX126x chipset family is not compatible with most of the listed libraries, and the ones that could potentially work would require using multiple libraries to handle different tasks, and this would have an impact on memory.

Also, although the LMICPP-Arduino sounded like a good candidate, however we did not want to change the compiler since this would probably have led us to a fair amount of adapting and debugging.

Another option could have been to write our own library, but this would simply have been too time consuming at this stage.

We gave up on the idea of this combination of ATMega328P and NiceRF LoRa1262-868… So, we kept our dear ATMega328P (since changing the MCU would require an extensive redesign of our PCB) and abandoned the idea of having the SX1262 based LoRaWAN device. To our benefit we found that the older G-NiceRF LoRa1276-C1-868 has an identical footprint and very similar pin connections.

SX1276-C1 pins 14-15-16 correspond to DIO0-DIO1-DIO2 respectively, and these also correspond to SX1262 pins NC-DIO1-BUSY (where NC is not used). Just by making this small change in hardware both modules can be used with the same PCB design, and only the software needs to be different. 
With this RF Module, we now had a number of choices for the radio communication library. The next big obstacle became the flash memory size in the ATMega328P, which is only 32KB (minus the size of the bootloader). In order to be able to use our POD logic that takes up around 10KB, our best choice was Arduino-LMIC, due to its reduced size in memory and apparently the simplest to implement. Arduino-LMIC is deprecated now, and the newer libraries listed above like the BasicMAC are recommended, unless there are tight constraints in flash memory like in our case.

We then assembled a makeshift POD (see Figure 4) to use as a test and proceeded to open the ttn-otaa.ino example code from the arduino-lmic library and tried to upload the code to our test device.

Since we were not using a board that is predefined in the library we needed to alter the code to set the correct pinmap (to avoid the compile error of Figure 5). In our case the pinmap was defined as seen in Figure 6.

If you’re trying this library don’t forget to also add your AppEUI, DevEUI and AppKEY to the code. It is compatible both for TTN and Helium networks. In our case we used the Helium network since we also work with some hotspots and are familiar with them. (When using Helium, and copying the AppEUI and DevEUI from the console, don’t forget to convert to little endian format – reverse the order of the bytes).

With the very simple Hello World payload example provided by the library we used up 64% of the MCU flash memory. That leaves us with a very small, but still doable, space for our code.

Using this library we could successfully turn our POD into a Class A LoRaWAN device, and we tested both uplink and downlink. Being a Class A device, we are limited to receive the server’s requests (downlinks) only shortly after sending data from the POD to the network (uplink), which changes the functioning of our system, and we cannot easily deploy this solution to our current installations on most clients. Other types of communications are possible in LoRaWAN (Class B and C) and this library does state that it is compatible with Class B, but not Class C, although we haven’t tested it.

As for future works to still make use of the superior (and original in our setup) NiceRF LoRa1262-868, we might be giving LMICPP-Arduino a try, but we will leave that update for another blog post…

… and to conclude

As it became evident, it is a bit of a stretch to use an ATMega328P as a complex LoRaWAN enabled device, but quite doable if your logic is not too memory intensive. Up to this point the library support for RF Modules is greatly in favor of the older generation of transceivers, and hopefully there will be updates on RadioLib, which is one of the most comprehensive all round libraries for radio communication that can be used in an Arduino environment.