Five Fundamental Considerations for a Battery-Powered Wireless IoT Sensor Product

Introduction

The Internet of Things (IoT) is upon us. According to an early report from Gartner, a typical family home may contain more than 500 smart devices by 2022, offering the promise that everyday homes will be smarter through the introduction of low-­cost IoT technology that is wirelessly connected and working tirelessly to simplify our everyday lives. But these features take energy, and most of these devices will be powered by batteries. This presents an interesting challenge for the developer as an IoT product in the connected home, must generally be of a small form-factor, made using the lowest cost bill of materials (BOM), and offer a reliable operation over several years without battery replacement.

1. Different Markets, Different Requirements

Before designing an IoT product it is important to understand its intended target market, as each market presents different requirements on cost, reliability, and battery life as illustrated by the following examples.

Subscription-based Service Providers

A subscription-based service provider, such as a cable or satellite internet provider, will tend to place greater importance on long-term, reliable operation over that of achieving the lowest BOM cost or smallest form-factor. Such companies need to weigh the costs associated with sending a technician for on-site troubleshooting versus the costs associated with the physical product itself. On-site support can run between $200 and $2000 per trip, according to various industry sources, and the cost of a device is often recovered through contractual rental fees passed to the consumer.

Do-it-Yourself (DIY) Home Automation

While the DIY enthusiast values reliability, such consumers often select products based on cost, size, and appearance. In this market, batteries are typically small to accommodate visually appealing enclosures, and a product’s BOM cost is usually low to achieve a low and competitive retail price point; therefore, product designers are willing to make several trade-offs to be more aesthetically pleasing at point-of-sale.

2. Battery Efficiency and Wireless - Not Always an Obvious Choice

When a product needs wireless connectivity, the choice of communications protocol will be a major factor that affects battery life. There are also several choices to consider, some of which may be preferred for a given application or even required by the target market.

Wi-Fi® is a commonly used protocol in consumer wireless products, as it accommodates large streams of data at high throughput rates but is more power-hungry compared to other wireless protocols. Wi-Fi tends to favor applications that allow for power outlets or the ability to use frequent charging, whereas other protocols are used in applications that run from a traditional battery and need very low data throughput rates.

Most home automation sensors, such as magnetic door and window sensors or passive infrared (PIR) motion detectors, lend themselves to long battery life requirements with only short bursts or transmission and with very little data. In such applications, Wi-Fi doesn’t make sense. These sensors can utilize battery-friendly wireless standards such as Bluetooth® Low Energy or Zigbee®. Bluetooth Low Energy targets direct point-to-point communication or mesh networking while Zigbee focuses only on multi-node mesh networking.

In the point-to-point home application, such as a smart lock designed to work locally with a smartphone, Bluetooth Low Energy might be the preferred protocol. For those looking to use minimal power with extended range in order to work with several other devices in the home, a mesh network (Zigbee or Bluetooth Mesh) may be a better solution.

Applications that often take advantage of mesh networks include thermostats, door sensors, and even window shades, as they can be configured to communicate autonomously with very little consumer interaction, and they also benefit from the built-in redundancy as single points of failure are eliminated. 

3. Duty Cycle - How Often Does the Device Communicate?

Once a developer decides on their protocol strategy, they must also determine the required transmission strength, the duration of a given transmission and the duty-cycle between any active and sleep state.

Most modern wireless transceivers offer sleep modes when not in use to save power; however, the sleep-state power numbers within the device’s electrical specification cannot be the sole consideration when calculating the device power budget. The wireless transceiver’s wake-up/sleep transition times, along with the processing algorithms prior to any transmission, should also be included when calculating the total wireless power budget.

The frequency, or duty-cycle, of wireless transmissions will directly affect the battery life of the product. Duty-cycle is determined in-part by the wireless standard requirements, the software algorithm, and how the device is normally used. For example, a door sensor with an open/close event will cause a wireless data transmission to occur; however, this sensor may also need to send and receive periodic wireless polling events to and from other mesh network nodes for status updates (such as battery health check).

Figure 1 provides an overview example of a sensor's power use.

Figure 1: Dynamic Current Draw of a Wireless Transceiver During One Polling Event

4. The Rest of the Design

In general, each application requires a certain type of sensor; a carbon monoxide detector needs a CO sensor, a smoke detector needs an ionization or photoelectric sensor, a motion detector needs a PIR sensor, and so forth.

Often these sensors themselves also add to the power budget calculation, gas sensors need to be heated and PIR sensors emit pulsed light. Other sensors may use less power but the microcontroller unit (MCU) in the design also uses power, particularly if it needs to analyze the raw data prior to a transmission.

When considering the operation of a sensor, developers can estimate battery life based on the applications themselves. For example, with a contact sensor used to detect an open window or an open door, the main sensor is a reed switch that detects the presence of a nearby magnet to determine if an entry point is open or closed. Once a magnetic field reaches a certain threshold, the sensor assumes the entry point status has changed and a wireless transmission is initiated.

The battery life cost can be calculated over a single instance of the cycle multiplied by the typical daily use case. The developer can then understand the coarse expectation as illustrated in Figure 2.

Figure 2: Contact Sensor Battery Life

In real life there are other complications to account for that may also continue to reduce that expectation. If the reed switch is held static in a specific state (open or closed) for long periods of time, it can further affect battery life should that state create a low series impedance circuit across the battery supply. In such a situation, designers can further enhance their designs to better the performance by adding kilo-ohms of impedance across the battery supply.

In a second example, a dimmer switch may be used to control Zigbee-based LED lighting nodes. The design use-case may be intended to offer hand-help operation and is therefore battery-powered. Aesthetics and design may require it use a small CR2032 coin-cell battery and capacitive sense to detect the user's physical touch and operation. To do this, the developer may choose to use the highly energy-efficient 8-bit EFM8SB1 MCU that has touch sensing capability and is designed to operate below 1µA while also offering an ability to detect multiple touchpoints and gestures for the lighting commands. The EFM8SB1 is specifically designed to monitor for such capacitive events in a relatively slow, millisecond duty cycle rate, matching that offered by a human response in such applications.

The more traditional MCUs that offer capacitive sense tend to be a lot more powerful making them less ideal for such low-cost applications, due to their increased current draw. MCU selection can often yield better results when matched to the application than when a developer simply selects the MCU based on familiarity.

5. Space Constraints and Stored Power in the Design

With the target market and electronic components that affect battery life considered, battery options can also be better assessed.

In general, smaller batteries have less storage capacity than the alternate larger options. The storage is typically quantified in milliamp-hours (mAh). A battery's chemical composition also plays into both its cost and storage effectiveness. Alkaline batteries, such as 1.5v AA and AAA, are very low-cost and possess high storage capabilities but they are large in size and prone to high leakage; these solutions work well for television hand-held remote controls.

Lithium batteries, such as the CR2 and CR123A are smaller in size and weigh less than Alkaline, but have a higher cost; therefore, these batteries are typically favored in designs that benefit from the small size and low leakage such as security sensors.

Table 2 provides an illustration of a typical Alkaline option versus typical Lithium-based options.

When these design considerations are fully understood, the outcome can be a lower-cost IoT sensor that can achieve an increased battery life for the required target market, but marching into design without considering them can put the product into a substantially less competitive position.