If you’ve got a LoRaWAN gateway, or are in range of an open gateway such as one using The Things Network, you need some sensors to start collecting data.
We will be supplying commercial sensors but for experimentation (and because it’s fun) I made my own.
In keeping with the design goals of LoRaWAN, I wanted the following features:
- low cost
- able to run off a small battery for at least a month (ideally much longer)
- easy to program without having to purchase device specific programming tools, ideally an Arduino compatible board
- capable of monitoring temperature and humidity with a reasonable level of accuracy
- data collected by The Things Network
I’ve done lots with Arduino boards over the years so using something compatible with that made a lot of sense to get something working quickly.
I wanted to make four sensors.
After a small amount of research, I found the Adafruit Lora 32u4 board and then the BSFrance clone of this. The BSFrance version of this is the cheapest board I’ve come across that incorporates a Lora radio with an Arduino MCU. It also includes a battery connector and a Lipo charging circuit so is easy to run from a small battery.
This board consists of an RFM95 LoRa chip connected to an ATmega32u4 microcontroller. These two components talk to each other using a protocol called Serial-Peripheral-Interface.
Then I searched for a combined temperature and humidity sensor device. I usually prefer using digital devices than analogue devices such as thermistors as I feel the manufacturer will have already done the hard work of converting the analogue readings into a usable value and will have done some calibration. In my experience, such devices give a more accurate reading with less effort.
I decided on a Honeywell HIH6130 chip (which I found on Farnell). It uses a protocol called i2c, this is a simple serial protocol which is widely supported by many embedded systems, including Arduino.
For batteries, the Lora32u4 board includes a Lipo charging circuit so I decided on using small Lipo batteries, the sort designed for small quadcopters/drones. I went for 600mAh batteries as they were very cheap! One thing I found is that the polarity of the connector was incorrect for the BSFrance board, so I had to remove the pins from the plastic housing and connect them the other way round. Be very careful, incorrect polarity and short circuits of Lipo batteries can cause fires and explosions.
So next, I got the HIH6130 datasheet, BSFrance Lora32u4 pinout diagram and a piece of paper to design my sensor circuit. As this is an experiment only, I designed it with a view to mounting on stripboard/veroboard. I ended up with this:
You may note that it shows a GPS module connected to the serial port of the Lora32u4 board. This was just another experiment I did with logging co-ordinates to The Things Network.
The next step is to translate this to a breadboard (prototyping board). Before that though, I had to figure out a way of mounting the HIH6130 as it is a surface-mount chip and so wont fit into either a breadboard or the stripboard I wanted to eventually use. I found these adaptor boards on Farnell. Expensive for what they are but solve a problem easily. Soldering the HIH6130 chips to these was fiddly, my tip is to use a small piece of Blu-Tac to hold the chip in place while you get the first couple of pins soldered.
I prototyped two sensors side by side on breadboard, the left hand one also includes a connection to a GPS board (which I already had lying around in a drawer):
That’s the hardware largely sorted, next is to write some software to make it do something. There’s lots of ways of writing, compiling & uploading code for Arduino compatible systems. In this instance I used a text editor/IDE called Atom with a plugin called PlatformIO, I used these because I specifically wanted to try them out.
Using the PlatformIO Atom plugin, it’s really easy to search for and install Arduino libraries. One of the advantages with Arduino is it’s popularity and amount of high quality libraries that exist for it. For this project I used:
- LMIC-Arduino: an implementation of the LoRaWAN protocol in C, ported to Arduino
- Low-Power: a simple way of making Arduino boards go to sleep and then wake up after a specific amount of time or in reaction to an interrupt
- SPI: needed for communication with the RFM95 LoRa radio chip
- Wire: this is part of the standard Arduino system (so doesn’t need installing separately). It allows you to talk to I2C devices. I did find a library specifically for HIH61xx chips, I can’t remember why I didn’t use it, I think it was because I found it just as easy to directly use the Wire library.
My program operates as follows:
- when the sensor starts up, it joins the LoRaWAN network using a device ID and application key. Using Over-The-Air-Activation process.
- then it enters a never ending loop:
- re-join if necessary
- read temperature & humidity from the I2C device
- read the battery voltage level from an analogue pin on the Lora32u4 board (the BSFrance board allows you to get the battery voltage)
- send data to the Lora chip
- go into low power sleep mode for ten minutes
Aside from the obvious task of actually sending readings to the LoRaWAN network from the sensor, there’s a couple of really important things it does.
One is to go into sleep mode, the device will spend the vast majority of it’s time in low-power sleep mode. This is what gives a sensor the ability to last a long time on a relatively small battery. Without this it will not last very long at all. If you are making a battery powered sensor then you want to make sure that is it spending most of it’s time asleep and that any unused peripherals on your microcontroller board are switched off.
The next is using OTAA and rejoining the network if needed. In LoRaWAN, a pair of security keys are used. Using OTAA these keys are generated during the join process and are not hard-coded into your sensor. The less secure method is using Activation By Personalisation (i.e. hard coding the keys into your device). This is not secure and should be avoided. when using OTAA it’s important for a device to re-join (and get new keys generated) if needs be (and it’s recommended to do this periodically anyway).
I uploaded this code to my four sensors (each one contains it’s own ID and application key) and they were happily sending data to The Things Network every ten minutes:
The last step for now was to put my sensors onto stripboard instead of breadboard so they are permanent circuits. I wanted to make the finished article as small as possible. There’s various pieces of software you can use for such things, I personally prefer just using paper and a pencil. You can download templates for printing off which have stripboard layout printed on them.
I usually end up drawing a few versions because once you have the first version you often see a way of making it smaller or simpler. At the end of this process, my finished sensor looked like this:
The small white wire on the Lora32u4 board connects the DIO1 pin to digital pin 6. This is needed when using the LMIC library (and possibly others, I don’t really know why the board comes without this as standard). I think newer versions of the board have a simpler way of doing this.
After making these sensors, I went on to program a simple dashboard that graphs the sensor readings, I will write another blog post on this later on.
I’ve had them running for about six months now, I’ve had no issues. I have found that the batteries last approximately two months before they need re-charging. I was hoping for a longer life than that but I am using very small 600mAh batteries, they are also very cheap from eBay and I have my doubts as to whether they really have this capacity.
I haven’t done any range tests, they certainly work anywhere in our building though.
This was a fun experiment and I have learnt a lot about how sensors work and are made, this is obviously way off a finished product and I have no intention of making it into one.
My experience tells me that if you want a sensor, always try to purchase an off the shelf device if you can. Making your own hardware gets more costly and time consuming than you can imagine.