Low power IoT devices and the possible use case in the grid
TL;DR: We researched low power communication technologies in order to determine a new way of collecting sensor and location data from assets. Our focus was to create an absolute low power solution, that’s why we choose LoRa to move forward. We did this by designing our own circuit board and writing our own software. All data is later collected in a backend we created ourselves. We used the LoRa device to control the energy consumed by a charge station as a next step.
Introduction
We see that the way we consume energy changes, and our grid is used differently than it was designed for 50 years ago. Consumers keep using more and more energy and with the addition of solar panels (PV) to a growing amount of homes and offices we are really stressing the limits of the grid at times. Thinking about the next few years we will see more and more people switching to electric cars (the annually power consumption of an individual car is equal to the power usage of a whole household). On top of that the Dutch government is trying to push households to stop using natural gas for cooking and heating their homes and use electricity (heat pumps) instead.
It is clear that the electricity grid is becoming quite complex and it is important to have connected assets in order to do proper monitoring and possible control usage. Currently this is done by connecting the assets to the GSM/GPRS/2G/3G network via SIM cards. This works, but with upcoming better/cheaper technologies for low power and long range communication it is worth the time to do research in order to improve. Also connecting sensors locally without any wire to a gateway would be a great improvement, for example for temperature measurements, atmospheric pressure, accelerometers or moisture sensors. Not all data has to pass ‘the cloud’, but could also be shared locally for monitoring.
Besides having a better, cheaper or more efficient way of communicating it would also be nice to have a way of determining the location of an asset. Right now the most common way of determining a location is by using GPS. However, GPS is not very low-power so having an alternative way to determine the location of an asset would be great.
For this project we looked into a few different LPWAN (Low Power Wide Area Network) technologies, the two most important being LoRaWAN and NB-IOT. Theoretical (online) research is a logical first step and we made a comparison between the two.
We determined we wanted to focus on low power with the ultimate goal to have a sensor device that would last multiple years on one battery while sending sensor data every 10–15 minutes. Looking at the above table we decided to start looking into LoRa(WAN) to get some hands-on experience. We still wanted to do some more research on NB-IOT in the future, which we did by talking to one of the commercial parties in The Netherlands that offer NB-IOT connectivity. Read further to find out!
Exploring LoRa(WAN)
LoRa (Long Range) is a spread spectrum modulation technique derived from chirp spread spectrum (CSS) technology and is the first low-cost implementation of chirp spread spectrum for commercial usage. It was developed by Cycleo of Grenoble, France, and acquired by Semtech in 2012, a founding member of the LoRa Alliance.
Getting started with LoRa was easy. We ordered some cheap LoRa modules from AliExpress and decided to buy a few gateways from The Things Network (TTN) to use it as LoRaWAN. Besides their great availability, we also like the idea of an open source community driven network!
LoRaWAN is one of several protocols that were developed to define the upper layers of the network. LoRaWAN is a cloud-based media access control (MAC) layer protocol but acts mainly as a network layer protocol for managing communication between LPWAN gateways and end-node devices as a routing protocol, maintained by the LoRa Alliance. Version 1.0 of the LoRaWAN specification was released in June 2015.
The Things Network was founded in 2015 in The Netherlands. The company launched a Kickstarter campaign to raise money for producing gateway hardware for LoRaWAN. The campaign raised €295,331 (of the €150,000 goal) by 934 backers. This was enough to start producing and selling affordable LoRaWAN hardware. Their goal was to cover The Netherlands with a LoRaWAN network.
The gateways were easy to install and within a few hours we were up and running. The nodes were a bit more challenging to get working. We used the arduino-lmic library which required us to solder some jumper wires in order to read interrupt pins required by this library. We were quite curious to why the company selling these boards did not connect these commonly needed wires. After sending some messages we received the PCB schematics and decided to take a look. Well… Uhmm… How do we say this? There was some room for improvements ;-)
After putting the jumper wires in place we were able to send and receive messages via the TTN network. The first working demo was born and we decided to focus on our goal of making the ultimate low-power sensor board. We hooked up our testing equipment here at ElaadNL and started looking at the power usage of the boards we bought.
We measured a power usage of a few milliamps in idle and above 100ma during transmission of data. While this is not bad and could give us quite some battery life we knew it could be done better. There were a lot of components on the PCB that were not designed for low-power applications and together with the onboard LEDs they accounted for a big piece of the total energy usage. We already saw a big drop in energy usage by removing the LED and that made us wonder how far we could go.
Commercial parties
Besides doing our own research online we like to speak with companies that offer services related to the technologies we are looking into.
The Netherlands has a fully covering LoRaWAN network hosted by KPN (one of the bigger mobile service providers we have). We quickly came in contact and a meeting took place a few days later. Besides offering data transmission, KPN is also doing localisation based on triangulation methods. This means that by using their network, we can combine sensor data with location data of all assets. We decided to cooperate with KPN and they supplied us with everything we needed to use their backend services. Thanks Dennis de Zwart from KPN for the great meeting!
For NB-IOT (Narrow Band IOT) we contacted another mobile service provider in The Netherlands but it quickly became clear there was a lot more needed to get started with NB-IOT. Higher device costs and the minimum amount of devices needed in order to get started were too high and we decided to not look into NB-IOT at this time. The technology is however interesting so we might use it in the future!
Now the real development begins!
We decided to design and produce our own LoRaWAN sensor hardware. This decision was made due to the fact that we want to create “building blocks” for future projects and research at ElaadNL. This LPWAN technology can potentially be used in assets we test and create so we want to have a mature solution that is easy to incorporate in the future.
The board should consist of the following parts:
- LoRa(WAN) module (RFM95)
- Microprocessor (Atmega328P)
- A very efficient power regulator
- A programming header
- An antenna connector
Luckily at ElaadNL we have some colleagues with experience in PCB design. Thanks to Klaas van Zuuren and Jesse Kerkhoven who jumped in and helped to design our own PCB. (We will link all design files and software files at the end of this blog).
We were able to design a PCB that had everything we needed within a nice small form factor. After checking (and rechecking and rechecking and rechecking) we decided it was done. Ordering the PCBs to be produced is easy but would still require us to hand solder all the (very small surface mounted) components. In order to speed up this process we searched for a Dutch company that could help us. We sent out a bunch of emails and after a few phone calls we decided to work with Productronics for our PCB production. Since this is our first time doing this we were very interested in all the steps it takes to go from design to a physical product. Luckily we got a call just before the PCBs would be assembled so we had the chance to go over there and check it out. Thanks Carlo from Productronics for the great service and giving us the chance to make this order into a great experience for us!
We received the finished PCBs a few days later. (Carlo from Productronics actually delivered them to us himself). The software we used on the cheap boards we bought at first was a great starting point for the software on our own PCB since we used the same RFM95 board for the LoRa(WAN) communication. However, we quickly found out that it was difficult to incorporate low power sleeps for the microcontroller in this library. LoRaWAN makes use of very specific timings and time windows for communication. The spectrum in which LoRaWAN operates is unlicensed, however we still need to respect the LoRaWAN specification.
We decided to implement the specific timings ourself in order to put the power hungry microprocessor and RFM95 to sleep when they are not used. This is a critical step in achieving a real low power usage so we have multiple years of battery life.
Choosing a battery
The choice for a battery for this demo still needed to be made. Batteries have some amount of self discharging over time. For this PCB that potentially runs for multiple years we want a battery that is not self discharging. We found a battery by Saft Batteries that has this property. These batteries discharge themselves less than 1% per year and they have an operational durability of 5 to 20 years. The batteries come in multiple form factors but since we want to finished product to be small, we decided on taking the 2600mAh variant. This gives us enough battery life while still being relatively small.
The potential of LoRa(WAN)
- Localization of devices
One of the potentials of LoRaWAN is to do triangulation via a multilateration algorithm, without the need of a GSM or GPS network. By just using the exact locations of the receiving gateways and the exact timestamps, the location of the devices can be calculated. This could be used for tracking of devices in a very low power way (sending once every 12 hours could result in battery life of 8+ years), although you have to keep in mind that the radius of the location might differ depending on the amount of gateways nearby.
We found out that KPN has a very good LoRaWAN coverage in the whole of the Netherlands, since they have a lot of gateways it also means that localization via their platform works surprisingly well. Even near the Germany border we found out that localization works quite well.
Use cases could be tracking assets like backup generators or other expensive equipment.
2.Remote sensors
Sensoring is usually the word when it comes to IoT. In our case we foresee that we could use LoRa(WAN) to send data from a sensor to a central unit in the field. This could for example be temperature data outside a transformer station, sent to the central unit using LoRa. Or ambient light sensor sending data via LoRa to the central unit for switching public lighting at the right moment, instead of at the right time.
In our demo we included the very small and low power BME280 sensor (3.6 μA) for temperature, humidity and (absolute) barometric pressure.
3.Grid control
LoRa allows to communicate directly between devices locally. There is no need to use a mobile provider or the cloud, it could all happen locally via a peer to peer connection. One of the things that could be done is to do load balancing on devices, directly controlled from the transformer.
Thinking of the grid in the near future, with the need of controlling power consumption (demand), this could be a solution which is reliable and makes the grid more resilient. A group of devices together with the transformer could then make sure they don’t overload the cable they’re connected to, or that the sum of power on all the cables doesn’t exceed the total power the transformer can deliver. Or when you go one step further, you could make sure that a group of transformers, with behind them a lot of devices, don’t exceed the maximum power of the medium voltage cable.
Also the production of sustainable energy in a certain part of the grid can be used locally (and thus no need for transportation/transformation), if we have communication between devices (or house holds).
This would create more resilient islands in the grid, which potentially could become self-sustainable and only need the rest of the grid as a backup solution.
The directly controlled charge station
One proof of concept and research my colleague Jesse Kerkhoven is currently conducting is a charge station equipped with a LoRa module that communicates directly with the transformer. In times of congestion on the grid the charger lowers its energy consumption. Since we are still in the process of researching and building I can’t give more details now but we’ll create a blogpost about it later on.
Lessons learned and things to consider
Unlicensed spectrum
LoRA make use of unlicensed (but heavily regulated) frequency spectrum, 433, 868 or 915 depending in which part of the world you live. In Europe 868MHz is quite common. However the frequency is unlicensed, it is heavily regulated for power and duty cycle (how much time ‘on air’ you’re allowed to use).
The question we raised: Do you want to rely on a free spectrum to do ‘mission critical’ communication?
Duty cycle, bit rate and range
The 868 MHz ISM band limits the use of a device to 1% of the ‘air time’. LoRaWAN specifies that each time a message is sent in one of the (sub)bands, the device must wait to comply with the duty cycle before it can send another message.
The time on air is depended on the bit rate but mostly on the spreading factor that is used. LoRa operates with spread factors from 7 to 12. SF7 is the shortest time on air, SF12 will be the longest. Each step up in spreading factor doubles the time on air to transmit the same amount of data, but increases the range you can reach. Sending very little data but with spreading factor 12 already makes the broadcast more than 1 second, which in return also consumes more energy.
This means that sending frequently needs to be considered carefully, and the data that is sent should be as little as possible.
OTAA or ABP
LoRAWAN supports two ways of ‘connecting’ to the network.
1. Over The Air Activation (OTAA). OTAA works with a hand shake that is done when a device connects for the first time, they agree on a shared secret for secure communication and from then on the device is registered. It also has the benefit that the gateway and the device can decide to lower the spreading factor, since the device is close enough to the gateway. This way the device can save energy and uses less time on air.
2. Activation By Personalization (ABP). ABP works with pre-configured keys that need to be configured upfront.
Both modes have 128-bits AES encryption by default. One on transport layer and one on the application layer.
Low power, real lower power and the lowest power
You have low power and real low power. When it comes to IoT devices that are battery powered the energy usage is the main factor you need to keep in mind. Especially when you’re not sending or doing calculations on the device (thus idle) it should consume really low power. In our experiments we saw that depending on the components we choose we saw a totally different quiescent current, and this matters a lot! I suggest you to read this article: Why Low Quiescent Current Matters for Longer Battery Life
In our case we ended up with micro currents when the device was idle, in the range of 4µA to 5µA. This was mainly achieved by choosing two components that make sure we have a very low quiescent current.
- A timer chip that cuts off all power to the micro controllers. The TPL5111 Nano-Power System Timer for Power Gating
- A LDO with a very low dropout with an output of 2.8V, enough to run the micro controller and the RFM95W. The SGM2019–2.8YN5G
We found out that not all off the shelf LoRa(WAN) devices are as low power as they say.
Antenna and epoxy
For testing purposes we wanted to have a waterproof LoRaWAN module together with a battery. The easiest solution? Put them in epoxy! Smart, but not so smart if you also put the antenna in the epoxy. We forgot that epoxy has a certain permeability, which affected the range of the antenna significantly. It’s important to not put the antenna in epoxy but keep it out of the epoxy.
Limited but reliable!
We found out that LoRa(WAN) delivers a extremely reliable connection, even at long ranges. However, it is also limited due to the fact that the bit rate is quite low. This means that doing remote firmware updates is a no-go, and sending a lot of high frequency measurements is also a no-go.
The technology is great, but should only be used for the cases where it fits perfectly. And thus the need of high bit rates is low, and when there is no need for remote firmware updates.
In a future blog we’ll tell you more about peer to peer energy control using LoRa in the grid.
Special thanks
I would like to give a special thanks to Klaas van Zuuren, Jesse Kerkhoven, Ton Smets and Dennis de Zwart (KPN).
The PCB Design
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
