Senses working overtime
The next generation of IoT sensors will provide devices with local intelligence that will measure a wide range of physical parameters, process this data locally and share the data on the cloud.
These sensors will be also be capable of processing and sharing information from multiple sensors, while consuming as little power as possible.
So how will we power these products in the future? Today, many rely on chemical battery technology but is the best way to power IoT sensors?
Legislation such as the European Battery Directive makes users responsible not only for the battery, but for its disposal, adding cost and complexity. Battery materials are also coming under more scrutiny as is the form factor and even the weight of the required batteries.
Many applications require longer product lifetimes than can be achieved with traditional battery technologies, so there’s been increased demand for more esoteric and expensive battery technologies, such as lithium thionyl chloride batteries. These can offer operating lifetimes of up to 10 years or more in some applications but are expensive and can have a significant environmental impact.
An application such as a structural health monitoring sensor can be embedded in a bridge or building for many years, but it can be difficult and expensive to provide access to it if you are looking to replace or recharge a battery so it’s necessary to find another power source.
Harvesting the energy to power sensors from the energy present in the environment addresses many of these problems, making it possible to recharge or even remove the need for batteries and support applications capable of running indefinitely without external intervention.
A simple batteryless IoT sensor, which measures temperature and humidity and shares the data on the cloud via a LoRaWAN radio is one such solution.
This application will run on a low-power microcontroller, which can be powered from a small solar cell, stores the energy from the solar cell in a supercapacitor, and controls the energy in the solar cell to manage the sensor and LoRaWAN radio power supply, optimising the energy efficiency of the application.
The first key component is the microcontroller as it needs to not only manage the system’s operation and all the processing requirements of the system, but do this with the power available. The Renesas RE01 microcontroller family is implemented on an ultra-low power process and can operate at high speed and low voltage while consuming very little power.
The RE01 consumes less than 25 µA / MHz in active mode and only 100 nA in deep standby mode. The RE01’s power architecture has multiple internal and external power domains, capable of working at up to 64 MHz and down to 1.62v and the device also comes with a wide range of low-power on-chip peripherals, including a 14-bit analogue to digital converter that can sample data while the whole chip consumes less than 4 µA.
The RE01 also has an energy harvesting controller which enables the device to operate with starting currents of only a few µA and provides support for the management of external rechargeable batteries and supercapacitors.
The RE01 can also use an on-chip internal low drop out regulated power supply to supply power internally; or to save power it can disable its internal supply and use a much more efficient external DC-DC converter to reduce power consumption. In the case of the evaluation board, the external power supply design using the Renesas ISL9213 can reduce the power consumption by almost 50%.
This application is built around the RE01-256K evaluation board, which includes various hardware connectors, such as an Arduino Uno interface allowing for easy prototyping of this application. This board also comes with a Memory in Pixel (MiP) Graphics LCD expansion board that includes a TN0181ANVNANN MIPs Display, providing visual indication of status while consuming current of less than 1µA on average.
Above: Sensor architecture
The board has also been designed to support energy harvesting as it also comes with a Panasonic AM-1815CA amorphous solar cell which can be connected directly to the RE01’s on-chip energy harvesting controller. The AM-1815CA provides a suitable trade-off, supplying enough energy to operate the sensor reliably while not being so large as to increase the sensor’s footprint.
In this example discussed here, we have chosen the Renesas HS3001 High-Performance Relative Humidity and Temperature Sensor which is an accurate, fully calibrated relative humidity and temperature sensor with a fast measurement response time, long-term stability and, most importantly, it consumes as little as 1.0µA during operation.
An integrated calibration and temperature compensation logic provides fully corrected relative and temperature values via a standard I²C interface. The measured data is internally corrected and compensated for accurate operation over a wide range of temperature and humidity levels without the need for user calibration.
An AVX supercapacitor can be easily added to the RE01-256K evaluation board to provide the energy storage element.
The final major component in this example is the SX1261 sub-GHz LoRaWAN transceiver. In this design, a SX1261 based Arduino shield that can be mounted on the RE01-256K evaluation board has been used, but users can easily replace this with a LoRa module on the SX1261 device itself.
Above: Sensor software architecture
LoRaWAN network architecture
A LoRaWAN network architecture is configured as a star-of-stars topology, in which a LoRaWAN gateway is used to send messages between end devices and a central network server. The gateway acts as a transparent bridge converting LoRaWAN packets to IP packets and vice versa to provide a robust set up connection to the central server.
In this design, a batteryless sensor has been designed to behave as a simple LoRaWAN Class A device – there are three classes, Class A, Class B and Class C, in which devices address different application requirements.
Class A devices are the default class and the functions must always be supported by all LoRaWAN end devices. They are also the lowest power consuming class of device. Communication is initiated by the sensor and is bi-directional and fully asynchronous. An uplink transmission can be initiated at any time by the sensor and is followed by two short downlink windows, RX1 and RX2. The timing of the downlink windows can be controlled by both the sensor and by the LoRaWAN server.
Class A devices are able to enter a low-power mode under application control and there is no requirement on the network for regular communication. Normally it is the best class to select when low-power operation is required to support occasional communication to update data in the cloud.
Class B devices add receive windows to the class A specification and are synchronised to the network using periodic beacons and open downlink ‘ping slots’ at scheduled times. This provides the network the ability to send downlink communications with a deterministic latency, but at the expense of some additional power consumption in the end device.
Class C devices reduce latency on the downlink by keeping the receiver of the end device open whenever the device is not transmitting (half duplex). Based on this, the network server can initiate a downlink transmission at any time on the assumption that the end-device receiver is open, so there is no latency – but continuous power needs to be available.
For this application, a proof of concept for the sensor mounts the Semtech LoRaWAN Arduino shield on the RE01-256K evaluation board to create the sensor assembly.
Above: Sensor Software flow diagram
An AVX supercap can be added to the evaluation board, as can the HS3001 temperature and humidity sensor and the MiPs display can be connected using the Pmod connector to give us a method of locally displaying the application status. This gives us a complete sensor and we only need the application software to be added.
This application is built on top of the RE microcontroller CMSIS drivers, which provide an easy to use hardware abstraction layer built on top of the RE01 chip hardware. These drivers make it easy to control the various peripheral functions of the chip without needing detailed knowledge of how the chip operates.
An interface layer is in place between these drivers and the SX1261 driver and the LoRaWAN protocol stack, which is provided by Semtech.
The main application will start once the energy harvesting controller has detected that enough energy is in the supercapacitor to run the main routine and provide enough power to operate the sensors and the radio.
To minimise the power consumption, part of the main application from Flash into SRAM initialises a low-power timer to generate an interrupt in 30 seconds to create the system cycle time. Having initialised all the power control systems, including the DC-DC converter and the low-voltage detection circuits it is then necessary to configure the MiPs display to show a logo screen. It will then be necessary to initialise the LoRaWAN radio and check the voltage on the supercap. If it’s too low, we enter a low-battery mode to allow the voltage level to recover.
The application then joins the LoRaWAN network, reads the sensor data, updates the MiPs display and sends the data via the LoRaWAN radio.
For many applications there is no need to share the data regularly – temperature and humidity, for example, rarely change quickly. As the radio uses the majority of the energy in this application, increasing the cycle time can significantly decrease the average current consumption.
This application shows that it’s possible to build a complete IoT sensor application that can be powered reliably by a small solar cell, without the need for a battery.
Depending on the lighting conditions that application is used in, it’s possible to measure the temperature and humidity once every 1–2 minutes, send the data to the LoRaWAN gateway and share the data in the cloud.
It’s also possible to use the same basic application hardware and software structure and replace the supercapacitor by a rechargeable battery if a different set of performance characteristics is required.
The use of easily available evaluation boards and a simple, downloadable software stack make it easy to try out this architecture and start to develop a batteryless sensor.