LoraWAN node with Bluepill, RFM95 & Platform.io

This post describes a quick, cheap and easy build of a LoraWAN node that can be used for example in the TheThingsNetwork

---

Introduction

This post will show hardware and code to realize a simple TheThingsNetwork LoraWAN node. This has been done already several times by other people, however not with the ingredients I used (Bluepill, RFM95, Platform.io). I am posting this here because it might be of help to anyone trying to cook the same soup as I did.

This post is a first one in a series of posts in which I will then use the node introduced here. Please be patient for the follow-ups 🙂

Hardware

The hardware is very simple: A RFM95 LoRa module connected to a Bluepill microcontroller board. To do this, you just need to route a couple of wires:

Bluepill	RFM95
3.3V	VCC
GND	GND
PA5	SCK
PA6	MISO
PA7	MOSI
PA4	NSS
PC14	NRESET
PA1	DIO0

Connections from Bluepill to RFM module

I also removed the resistor to the power LED (R1) on the BluePill to save ~2mA:

Removed power LED resistor R1

On one of my BluePill boards I also removed the 3.3V regulator but I could not notice any significant reduction in power (when backfeeding directly 3.3V into the BluePill). So I recommend to leave the LDO as is.

The final hardware is shown in the following picture:

LoraWAN node hardware

Software

The software I used on my node is based on an ATTiny node ( https://gitlab.com/iot-lab-org/ATtiny84_low_power_LoRa_node_OOP ). I removed all the sensor stuff so that it just sends a fixed dummy message. But the largest part was porting it to the STM32 based BluePill. For this, I removed all AVR specific parts and added some low power STM32 routines. The code now sends a message every 20s and sleeps in between (consuming ~0.3mA). The consumption is still a bit on the high side but for now it is ok for my upcoming projects.

You can find the software here: https://github.com/befinitiv/lorawan_bluepill_node

Building it with Platform.io should be self-explanatory. You might however need to adapt your programming hardware in the platform.ini file.

Before building you also need to copy the file secconfig_example.h to secconfig.h and fill it with the keys you get for example from https://thethingsnetwork.org/ for your node. I did not include my keys in the repository for obvious reasons 🙂

After you programmed your BluePill you should see a new message in your thethingsnetwork.org console every 20s (if you have a gateway in range).

Range test

I tested my node with a Lora spreading factor of 10, which is AFAIK the maximum supported by thethingsnetwork.org. With this I achieved some quite impressive results.

The first test I did was in the basement of my house. From here I could reach a gateway with quite a good signal strength of -91dB at a distance of 500m. What is impressive is that the line of sight crossed several blocks of 5 story buildings that are typical for the inner city of Berlin.

The next test was even more impressive. I took the node out on the street and monitored which gateways receive its data. And I was quite surprised to see that it reached close to 2km from ground level in the inner city of Berlin! One such example is shown in the following image:

In case you have never been to Berlin: For the most part, the city is extremely flat. This means that in the image above there was absolutely no clear line of sight. The signal passed through dozens of buildings and blocks. To be honest, I really have troubles imagining how the signal got through these obstacles. Really impressive.

Some final thoughts

Platform.io

This project was the first time that I used Platform.io to build my code. Previously I was going more bare-metal with Makefiles et al. My first impression was: Wow, this makes embedded development really simple. Defining the hardware platform in just a handful of lines in platform.ini file is enough, everything else happens under the hood. Download of the compiler, debug tools, libraries, etc. This was a nice surprise.

Still, when I let the graybeard in me speak I am troubled by all the dependencies Platform.io creates to a number of diverse parties. This is all good if everything is working but my fear is that in 5 years from now many of these dependencies will be broken and the code will not be buildable anymore. It is a bit like an illness of modern times, comparable to for example NPM. These systems let you start smoothly but as soon as something breaks you notice how little control you actually have.

TheThingsNetwork

This project is also the first time I am using TheThingsNetwork. And I must say that I am quite pleased with the service they are offering. So far, the RF technologies in use by me are Wifi & Bluetooth LE. Both of these work well in cases where you spawn your own infrastructure (Access point for example) but are pretty much useless where this is not possible. The only alternative I knew so far was cellular networks like 4G. But their complexity and subscription model was always keeping me from using it. TheThingsNetwork adds a new tool to my RF toolbox that fills a gap: It works on a large area without building up my own infrastructure, it uses “low” frequency bands, so the penetration capability and range, especially in urban environment, is fantastic. On top of that, the service is free, the hardware is cheap and the whole setup is relatively simple. What more could you ask for? 🙂