Battery life and power management are two of the most important considerations when designing Internet of Things devices. Many nascent IoT use cases require equipment, machines, vehicles, and physical assets to be disconnected from the electrical grid because they’re deployed in remote locations or are mobile.

In cases where replacing batteries is difficult or expensive, your ability to balance power management with performance and usability can mean the difference between a successful connected product and a failure. Low power can’t mean low performance.

In this article, we’ll look at:

• What “low power” means in IoT and why it’s not as straightforward as you might think
• Why power modes matter just as much—if not more—than the electronics themselves
• Common use cases for low-power IoT
• How you can find a solution to build low-power devices

What Does ‘Low Power’ Mean in an IoT Context?

The short answer is, “it depends.”

“Low power” is a relative term, so there’s no straightforward answer here. After all, low power for a Particle cellular device is very different from low power for an iPhone (another type of IoT device).

To understand why low power is such a contextual descriptor for an Internet-connected device, let’s look at two use cases: an iPhone 13 and a cellular IoT device from Particle that monitors an oil and gas asset.

Putting Low Power Into Perspective

When a Particle cellular device actively sends data to the cloud, it typically consumes 66.3 mA. Since that value—66.3 mA—doesn’t mean much to most people, let’s put it into perspective.

According to this blog, which analyzed various iPhone models across different usage modes for battery life, the iPhone 13 has a 3,227 mAh battery that can last approximately 14 hours while a user is doing basic web browsing.

That’s really impressive…

…but 14 hours will not cut it if you’re designing a solar-powered IoT system to remotely monitor oil and gas assets in far-flung Canadian oil fields in the dead of winter. This scenario may seem oddly specific, but it’s a real-world IoT use case for Particle devices.

If we were to take that same iPhone 13 battery (3,227 mAh) and use it to power a Particle B SoM while transmitting data and consuming 66.3 mA, we would expect the battery to last around 40 hours.

That’s better, but again, still likely not enough of a margin for issues that may arise in the oil and gas case described above. For example, if a storm rolls through and prevents the solar module from producing energy for a few days, the device won’t have power and you won’t be able to monitor your asset.

Although the iPhone offers battery and power management capabilities that are superbly optimized for how a consumer uses a mobile phone, it isn't well suited for use as an oil and gas monitoring device.

Why Modes Matter When Designing IoT Devices for Low Power

Continuing with the previous example wherein the Particle B SoM is estimated to last ~40 hours, let's tweak our assumptions a bit.

Imagine we discovered that this IoT device only needed to be on for half the day, and we could program it to turn off for the other half. That would get us about 80 hours of battery life.

If that’s still not enough of a power budget for this use case, we could adopt a mechanism for turning off the radio (one of the more power-hungry aspects of IoT devices) but not the application processor. This would allow the device to continue collecting and queuing/buffering data for later transmission. These optimizations could get us to ~160 hours of battery life—in other words, four times the original estimate.

As you can see, the impact of using different operating modes is huge, which is something the best IoT product designers and engineers understand.

Thus, designing “low power” IoT is not only about having the most power-efficient subsystems, such as computers, cellular modems, power delivery, and storage. It’s just as much about controlling the modes your IoT device operates in.

As visually demonstrated in the figure below, the modes you choose greatly impact your overall energy budget.

An example of how different modes can impact power consumption in a device. 

Four Critical Use Cases for Low-Power IoT

The need for low-power IoT isn’t necessarily industry or vertical-specific, but rather use case-specific. Wherever you need to have a battery powering your electronics, you’ll want to be intentionally efficient with how you use that battery’s life.

So, what are the use cases where you would need a battery?

Mobile Assets

The term "mobile assets" refers to devices, machines, vehicles, or equipment that move around based on user behavior. These devices need to be reliably connected to the Internet no matter where they are, so battery life is critical.

Mobile assets need their energy supply built into them—for instance, in the form of batteries in IoT-connected micromobility vehicles or medical equipment that gets moved between different hospital units.

Although these assets typically have business operations around them to refill their energy storage systems, those operations are expensive and usually require human intervention. In these cases, you'll want to reduce those “top-up” events, which you can do by making their energy systems more low-power and efficient.

Remote Fixed Assets

Here, "remote fixed assets" refer to stationary IoT devices that don’t have access to the electric grid.

RFAs also require a built-in energy supply, but since they’re stationary, they can use solar charging to perenially “top up” their storage systems. In addition to the remote oil and gas site mentioned earlier, agricultural IoT, remote emissions monitoring, and even traffic monitoring systems would be illustrative examples here.

Low and efficient power systems are still relevant for RFAs because they allow you to design with smaller solar cells, charger circuits, and battery banks, which will lower your bill for material costs.

Critical Assets

"Critical assets" refers to IoT devices that are tied to the electric grid but required to operate even—or especially—when the electric grid has an outage.

For critical assets, adding a backup battery to be used if the power supply goes away is the optimal design decision. In examples such as medical IoT devices and IoT-enabled smart energy devices (EV chargers, smart meters, etc.), a power outage could lead to critical asset failure, resulting in damage, downtime, or even injury and death.

Wearable Assets

A "wearable asset" is any IoT device that a human would wear or interact closely with.

Of course, higher-power and -voltage (>30 Volts) systems have the potential of causing electric shock and even death in humans, so keeping your systems below that level of voltage will protect users and reduce your certification, liability, and reliability testing costs.

Low Power Is Usually The Way to Go

Outside of the asset categories we just explored (mobile, remote and fixed, critical, and wearable), devices typically don’t require as much scrutiny when it comes to having low and efficient power.

That said, there are typically cost and safety savings to be had when designing with lower-power electronics. While this may not always be feasible, it’s worth designing for lower power when you can.

Common Challenges in Designing Low-Power IoT Devices

Designing low-power IoT devices requires teams to make tradeoffs and consider how the entirety of their design—from hardware to system design—impacts power consumption.

Performance vs. Power

Ultimately, the most important tradeoff you must be aware of is performance vs. power.

CPU, memory, and data bandwidth are key enablers for IoT devices' performance in their respective use cases. Any use case with strict requirements for high performance, such as Internet-connected cameras on autonomous vehicles, will have to make some compromises on low power.

Making Hardware and System Design Work Together

Beyond that, the core challenge of designing low-power devices is finding best-in-class hardware AND having an overall system design that uses different modes of operations to lower energy consumption.

Here are some key questions you should be asking yourself or your IoT partner as you design your devices to ensure they have the low-power capabilities you need:

• How often can I put my device to sleep?
• How much data do I need to send? Can I lower that usage in the future?
• Should I do the data crunching/analysis on the edge or in the cloud?
• Is there a latency requirement between when a certain event is recorded and when that event is transmitted to the cloud?
• If my device is asleep, what triggers do I need to be able to wake it up?
• What network problems will arise if my device is going to sleep too frequently?
• What battery life do I need, what temperatures does this battery need to operate in, and which battery chemistry is right for my use case?

Finding an IoT Solution for Low-Power Applications and Use Cases

Whether you design your own devices or use those of an IoT solutions vendor, it's important to determine whether the tech can support the low-power needs your use case demands.

That means evaluating your potential solutions based on the electronics' power-efficiency and your level of control over the power modes.

Building for Low-Power Use Cases With Particle

Particle’s IoT hardware and Particle Device OS—our embedded IoT operating system—were built with these two levers in mind. As a result, our IoT Platform-as-a-Service delivers both an integrated set of power-efficient electronics AND a comprehensive and simple set of “power mode” APIs to control them.

Device OS allows you to easily configure your device’s power consumption with simple APIs built into the operating system that transition your application in and out of unified low-power and sleep.

On the hardware side, Particle devices are standardized to be off-the-shelf ready to design low-power applications. That said, all of our devices are flexible, extensible, and fully configurable. You can use different variations of hardware components to build your finished connected product, including varying components for antenna, enclosure, power, battery, sensor, and actuator interfaces.