With the advent of the IoT, small, widely distributed sensor nodes will proliferate. Most of these will be battery powered and must be in remote locations for long periods of time. It is essential to make them as power efficient as possible by combining a host of design considerations.
by Matt Saunders, Silicon Labs
We have long seen the need across all industries and markets for energy-efficient, battery-powered devices that offer long service life. With the rise of the Internet of Things (IoT), embedded designers are, more than ever, focusing their attention and efforts on power management for “stingy” devices. This is especially true when considering battery-powered devices that require some form of wireless connectivity, whether in a simple point-to-point wireless network configuration or a more complex star or mesh network. There are many applications that could be considered a good fit for the stingy device category. A prime example is a wireless sensor node — a relatively simple device from a functional point of view that is required to do its job for an extended period (up to several years in some cases) while powered by a battery.
To build a successful product for such an application, the developer must consider many aspects of the overall design. These design considerations include not only the microcontroller (MCU) and its degree of energy efficiency but also other elements in the system, such as the wireless interface (not just the physical implementation but also the wireless protocol used), system-level power management (e.g., the low drop-out regulator integrated into the MCU or dedicated power management ICs), the sensor itself, and analog functionality required to collect and process sensor data. Figure 1 shows the key elements of a wireless sensor node.
Figure 1: Typical Wireless Sensor Node Architecture
For a battery-powered wireless sensor node, the MCU will need to be extremely energy efficient. RF protocol and data manipulation requirements (used perhaps for signal conditioning and digital signal processing) will likely dictate whether a 32-bit or 8-bit MCU is necessary, but, nonetheless, many low-energy requirements will remain the same regardless of the MCU choice. For example, being able to wake up from extremely low power modes to full-speed operation in a short span of time (e.g., 2 µsec) will make a significant difference in conserving battery power. The faster the MCU wakeup time, the better in this case. While the MCU is transitioning between power modes, it is effectively doing nothing useful.
Two additional parameters that also have a significant impact on system-level power are the energy consumption in low-power modes (should be <1 µA) and the consumption during active modes. This varies depending upon the MCU core used and the process technology node for the MCU itself and should be in the range of 150 µA/MHz or less. There are other factors that influence energy efficiency, but these three factors—computational requirements, low-power mode consumption and active mode consumption—are all essentially architectural considerations and will guide the MCU choice for the application.
System designers should also carefully consider how much the chosen MCU can do without actually leveraging the CPU core itself. For example, significant power savings can be achieved through autonomous handling of sensor interfaces. Being able to generate the stimulus signal (or power supply) for the sensor from the MCU and read back and interpret the results without waking the MCU until “useful” data is obtained can go a long way toward maximizing the system’s battery life. Some MCU architectures are designed to provide autonomous sensor interaction. For example, as shown in Figure 2, Silicon Labs’ EFM32 MCU architecture combines an autonomous low-energy sensor interface (a peripheral called LESENSE) with onboard comparators to collect data from an external sensor and wake the CPU only when it has valid or useful data, all for a suitably stingy power budget of 1.5 µA.
Figure 2: Low-Energy Sensor Interface (LESENSE) Technology Used in 32-bit EFM32 MCUs
While there are other energy-saving aspects of an MCU to consider for stingy applications, we still have a lot more to cover for our simple wireless sensor node application example. Moving on to the wireless connectivity element, we can consider several significantly different options. The network topology (Figure 3) and the choice of protocols will both have an impact on the power budget required to maintain the wireless link. As shown in Figure 3, there are some cases where a simple point-to-point link using a proprietary sub-GHz protocol may seem like an appropriate choice as it would likely yield the lowest demand on power from the battery. However, this simple wireless configuration limits the scope of where and how the sensor can be deployed and still be useful.
Figure 3: Network Topology Examples
A star configuration built on either 2.4 GHz or sub-GHz technologies increases the flexibility for sensor deployment, meaning multiple sensors can be deployed in the same network. However, this would likely increase the complexity of the protocol required to transmit data, therefore increasing the amount of RF traffic and thus the power drain on the battery.
A third option to consider is a mesh configuration based on a protocol such as ZigBee. While a mesh network imposes the biggest drain on the sensor node battery, it also provides the greatest level of flexibility for deployment including node-to-node data transfer. Depending on the wireless stack (such as ZigBee), a mesh network can also provide the most reliable deployment option with a self-healing network in which despite the failure of one node in the mesh, the messages can still find another path to their destination.
Closely related to the choice of network configuration is the quantity of data that must be shifted from node-to-node or from node-to-collector. In a sensor node, the amount of data to be sent over the wireless link should be relatively small, especially if some of the data is processed on the node’s MCU and only relevant information, rather than all collected data, is transmitted. As such, ZigBee provides an optimal mesh networking solution; Bluetooth Smart is an excellent choice for standards-based, power-sensitive point-to-point configurations, and proprietary sub-GHz solutions provide maximum flexibility for network size, bandwidth and data payloads in star or point-to-point configurations. Table 1 summarizes many of the key features and benefits of leading RF technologies used in IoT applications.
Table 1: Primary Differences between RF Protocols
It is also helpful to consider long-range technologies and platforms, such as LoRa and Sigfox, which enable high node-count networks with connections that can reach up to tens of kilometers and still support low-power systems. Using these long-range wireless technologies, it’s possible to deploy stingy sensor nodes over very wide areas.
An additional consideration for the wireless link is the encryption used to protect transmitted data. How encryption is handled can have a major impact on stingy devices. For example, ZigBee has encryption built into the stack, but if the MCU (or processor core) used to run the stack does not have the correct encryption hardware, it will have to burn multiple cycles to run the algorithm in software. For example, managing a 128-bit AES encryption algorithm on an ARM Cortex-M0+ processor with an AES hardware accelerator takes 54 cycles while managing the same algorithm without hardware acceleration takes more than 4000 cycles, approximately 80 times longer than the MCU with hardware crypto support. This has a significant impact on the overall power consumption of the sensor node when it sends or receives data on the wireless link. In the IoT market, there is an increasing demand for security on wireless links. As more complex cryptography requirements are imposed on wireless networks, this security-driven element of power management for stingy devices is becoming increasingly important and will have a significant influence on the hardware choices made by developers.
Regarding sensors used in our node example, numerous sensor choices are available, ranging from optical to environmental and motion. The choice of sensors ultimately is dictated by what you are trying to measure. For our example, we will choose ambient light levels. There are several options for measuring ambient light, starting with discrete sensing components, which could be designed to achieve very low power, but this approach puts the signal acquisition and processing burden onto the MCU. As a result, the MCU will be in active mode for longer periods of time; more peripherals, such as analog-to-digital converters (ADCs), will remain active, and the overall system power consumption will rise. An alternative approach involves using an ambient light sensor with built-in intelligence, as shown in Figure 4.
Figure 4: Ambient Light Sensor with Built-in Signal Conditioning
Building signal conditioning into the sensor provides some significant advantages. The data that is sent to the MCU will be relevant data that can be quickly and easily interpreted by the application, which means the MCU can stay asleep longer. Having preconditioned data sent over a digital interface, such as SPI or I2C, also means the MCU can gather the data more efficiently than if it were using its ADC. While this example is specific to ambient light sensing, there are many other sensors that follow a similar path of including built-in intelligence and providing data to the host MCU that is immediately actionable with a goal of reducing overall system power consumption.
A final design consideration for stingy device applications is simply powering the system itself. Depending upon the type of battery used in the application, there is often a requirement for boost converters or boost-switching regulators if more voltage or current is required than the battery can deliver. For example, if you are running from a single cell at 1.5 V but need to generate 3.3 V for the MCU, then you will need to support this function when considering overall device power management. A careful choice here can again have a big impact on the system’s overall power consumption. Plenty of boost converters are available with consumption figures in the range of 5-7 µA, but that is a hefty penalty to pay if you are going to be in sleep mode most of the time. There are options for boost converters with 1 µA consumption and even as low as 150 nA (while maintaining a high boost efficiency).
For more complex systems, it is worth considering a power management integrated circuit (PMIC) to give more precise control over the whole system. From a single power source, you can generate multiple voltage rails to drive different elements of the embedded system, tuning each voltage rail to provide just enough power for what the application needs without wasting any power. For example, you can dedicate a supply to the radio in the system that is separate from the MCU, meaning that if the protocol permits this capability, the radio can be completely turned off when not in use. Or, if you have an MCU that provides the option to supply the I/O ring and the core separately, you can again achieve optimum MCU energy efficiency by using a PMIC, also supplying a separate voltage rail into the sensors used in the application.
A high-quality PMIC will also offer additional functionality for general system control, such as watchdog timers and rest capability. A PMIC is not going to be suitable in all applications partly because of the additional cost, but in applications that can bear that additional cost, the PMIC approach represents an excellent way to manage overall system power for stingy applications.
In conclusion, there are many different system design aspects involved in developing a battery-powered stingy application. Not only the semiconductor components used but also the overall approach to software, including wireless stacks, encryption and data processing, are important considerations. Each of these design elements can have a significant effect on the system’s overall power budget, enabling you to create stingy devices that maximize useful battery life, and isn’t that what good IoT system design is all about?
Silicon Labs, Austin, TX. (512) 416-8500. www.silabs.com