Market researcher IHS, for example, is forecasting that shipments of connected home device could grow from 59million units in 2015 to nearly 200m by 2018. While sensor-based networks for monitoring and control are not new concepts, demand for wireless implementations – previously limited to just a few niche markets – is set to grow as companies look to benefit from the combination of installation simplicity and low-cost.
Wireless systems need to consume as little power as possible and next generation networks are being developed where batteries require little maintenance over the application’s life time. As an alternative, there is also a focus on energy harvesting to provide the necessary power, removing the need for batteries completely.
The deployment of energy harvesting is not straightforward, however, as Øivind Loe, a senior marketing manager responsible for Silicon Labs’ 32bit EFM32 Gecko MCU portfolio, explains.
“Energy harvesting is becoming more attractive because it doesn’t require continual recharging and does away with the need for communication or power wires. The challenge with its deployment comes when it needs to be located in more challenging environments and especially when power needs to be stored. If you have to incorporate temporary storage capabilities in a design, then the application will, as a necessity, become far more complicated – cost, as a result, then becomes a more important issue, especially if you are distributing hundreds or thousands of sensors.
“Applications have different power requirements. A door lock, for example, may only have to report back every hour or when something happens. As a result the power requirements will be low. By comparison, some wearable devices, such as the Apple Watch, consume far too much power to deploy a harvesting solution. The challenge is being able to develop an MCU that is capable of driving an application but which comes with very low power consumption.”
According to Loe, a key issue when powering sensors is that energy harvesting may only be able to supply as little as 10µA continuously, especially if the energy source is a small solar panel.
“By contrast, a microcontroller executing code will have power requirements hundreds or thousands times greater. As a result, application designs will need to be able to fully leverage various sleep modes and should be designed with a view to putting the application into sleep mode as much as is possible.”
Most applications will come with a variety of preset operating modes, so the embedded microcontroller can, for example, be put into a ‘sleep’ or enter an extreme, low-power ‘standby’ mode in between different data samples. If the microcontroller collects sufficient data, it can then switch to a ‘fully on’ mode, where it is awake and running at maximum operating speed.
This will require the microcontroller to receive some kind of wake-up event, which could be triggered by an external event or by internal processor activity.
From an ‘always on’ mode to a ‘sleep’ or ‘standby’ mode, where memory stays powered, or a ‘deep sleep’ mode, where the memory is powered down for maximum power savings, the choice of a microcontroller's power modes can have a significant impact on the overall power requirements of an application.
“Most of the problems with deploying energy harvesting solutions come when you look at the mechanism that sits closest to the energy harvesting elements,” explains Loe. He continues “For example, the energy output might be too low to power up the MCU. Starting an MCU will require a lot of current; more than the energy harvesting component can provide. As a result, you need to deploy a mechanism whereby the MCU will only start-up when sufficient energy has been stored, usually a capacitor to store the energy and a comparator capable of detecting the amount of power available.
“Once the application has powered up, it can then return to a more suitable power mode. It means the application has greater stability.”
Accurate timing is needed to ensure the wireless sensor transmits information during a predefined assigned time slot, which will enable multiple wireless sensor nodes to work together.
When it comes to the overall power budget of the wireless system, the transmit power consumption, the receiver power consumption, the standby power consumption, and the start-up time are all important considerations and will determine how much current the unit will consume when transmitting and receiving data.
However, if you are looking to minimise the overall power consumption, it is not enough to simply select the lowest-power mode on the microcontroller as the amount of work needed to complete each of the tasks will need to be taken into account and as the Internet of Things develops and the amount of data collated rises, how and when that data is processed will become more important.
The adoption of energy harvesting, however, is being held back by a combination of issues around cost and reliability, according to Keith Odland, senior director of marketing for Ambiq Micro.
“At the moment, batteries remain the dominant way in which power is stored and delivered. While there has been a lot of discussion around energy harvesting, it really hasn’t taken off.
“When you develop a network, there will be a power budget for computation and for communication. Hopping from one node to another to get that data to a point where it can be processed can be described, in effect, as an energy tax that you are taking from that packet or payload. Minimising those hops could be one trade-off leading to more localised processing should those tasks be more power intensive. Could that impact the shape and size of the network? Perhaps,” Odland concludes.
In many low-power saving mode systems, the application’s battery life will often be affected by the current consumption of other components in the PCB and this needs to be considered.
Designers will also need to determine which other circuits need to be powered in the low-power state of the application.
“Power requirements will have an impact on the roll out of the Internet of Things,“ suggests Loe, “but everything will depend on the application. It may well be that light could make an excellent power source, or a more mechanical energy harvesting solution might be more suitable. We are also seeing a lot of interest in remote charging technologies.”
Both Loe and Odland identify cost and power among the challenges to rolling out of IoT applications, but note that, further down the road, security is another consideration.
“Consumers will start to worry when they begin to realise the devices they are using are less secure than they thought. Additional security will have an impact on energy requirements – it might not be significant, but it will be measureable – and when you are looking to reduce power consumption, even at the micro or nanoamp level, any impact on the power envelope has to be taken seriously,” Loe says. “When you connect to a network, there are some expensive operations that need to be carried out and that will have an impact. Any security features will need to be low power.”
