Maximizing Battery Life for Remote IoT Devices

For many IoT deployments, long-distance visibility is the whole point. Smart agriculture, asset tracking, pipeline, and environmental monitoring all operate across huge geographical distances, with devices scattered far and wide. That means your devices end up very far away from everything that usually makes technology work, affecting the battery life for remote IoT devices.

Without access to the power grid, energy has to come from batteries. Changing those batteries is expensive and time-consuming, assuming it’s even possible. It probably isn’t when your devices are in the middle of the ocean, at the top of a mountain peak, or seeded across the Australian Outback. 

To make business sense (let alone technical sense), far-flung IoT devices have to be incredibly energy efficient. They have to recharge themselves somehow, limit power usage, or both. In other words, battery life is a key challenge for remote IoT deployments. 

Here are a few ways to increase the battery life for remote IoT devices, no matter how far off the beaten track you deploy your IoT devices.

5 Ways to Extend Battery Life in Remote IoT Deployments

Energy usage in IoT always depends on your connectivity technology. Remote deployments tend to rule out cellular modems—there’s simply no coverage—which leaves non-cellular-based LPWAN (e.g. LoRa) and satellite connections.

However, you can think of satellite IoT as a form of LPWAN. You don’t usually see it described as such, but that’s exactly what it is; individual sensors communicate with satellites, which in turn transmit the data via a ground station to your servers for interpretation.

With both options - non-cellular-based LPWAN, and satellite LPWAN - you have power constraints. Broadly speaking, the more data you send and receive, the more power you’ll require; and satellite gives you the flexibility to send larger volumes of data than LoRaWAN (plus the data needs to travel further). This means considerations for battery conservation are particularly relevant to satellite IoT deployments. When you plan your next big satellite IoT deployment, then, keep these five tips in mind:

#1: Send as Little Data as Possible

Some of the most energy-efficient satellite IoT devices on the market only use a tenth of a watt to sit idle. When that same device transmits data, however, energy usage shoots up to 7 watts—an increase of 7,000 percent!

Every IoT device follows the same law: the more data you send, the longer you transmit, and the more energy you use. If you want your batteries to last, then, you have to send mission-critical data only. Identify the data points you need to meet your goal and get rid of everything else.

#2: Send Data Infrequently

As we’ve established, transmitting data takes a lot of power, affecting the battery life for remote IoT devices.. Limiting the volume of data extends battery life, but so does limiting the frequency of data transmissions. 

Take a standard GPS tracking device, for example. If it reports its location every five minutes, the battery might last for a week. Transmit once per hour, and battery life grows to three weeks or more. Send data once per day, and now you’re looking at a six-month battery life. 

The same principle applies to every IoT device. To get a long battery life, then, it’s important to right-size your transmission schedule. If you can get away with daily or weekly reports, your device will live much longer than one that’s constantly sending data.  

#3: Process Data at the Edge 

How exactly do you go about sending less data, less frequently? You must analyze data at the point of generation, so the system can identify crucial data for transmission while ignoring the rest. In other words, you need data processing at the edge.

With edge computing capabilities built into your satellite transceiver device, you can report by exception. (Why waste battery power saying “system normal” over and over?) You can prioritize data according to your needs. And you can compress data before transmitting.       

#4: Use Message-Based Protocols 

If you’re used to cellular IoT, you might assume every IoT data connection should use an internet-based protocol like TCP/IP. In a satellite IoT deployment, that’s probably not the best choice. Why? Because TCP/IP is a resource-hungry protocol. It’s always on, for one thing.

It also requires multiple authentication/overhead messages surrounding the actual data you want to send. The TCP/IP protocol simply wasn’t designed for the low data volumes involved in most IoT use cases. 

Cellular IoT can use the Non IP Data Delivery (NIDD), which is message-based—more like a text message than a video call. There are also proven message-based connectivity protocols for satellite systems, like Iridium’s Short Burst Data (SBD), Iridium Messaging Transport (IMT), or Inmarsat’s IsatData Pro.

#5: Harvest Energy

Solar panels aren’t a substitute for data optimization, edge processing, and message-based protocols. They’re simply not efficient enough to replace batteries entirely. They require sunny conditions and, often, lots of space and infrastructure. 

That said, solar power can help to extend the lifespan of some remote IoT devices—in conjunction with batteries, of course. For example, a satellite transceiver called the Iridium Edge Solar can run on solar panels for up to 10 years, with a backup battery for another five years of service—if you optimize data transmission schedules.

Extending Battery Life

Ultimately, remote IoT deployments require a ground-up strategy for extending battery life. You certainly need resilient, energy-efficient hardware. Look for a transceiver that consumes less than a quarter of a watt in receive mode, and maybe an on/off switch capable of Pulse Width Modulation (PWM), an energy-saving technique that operates sort of like a light’s dimmer switch. 

But even the most energy-efficient hardware will burn out if you don’t plan for optimal data usage. When your IoT devices are too far away for hands-on maintenance, data optimization is the key to success for the whole deployment.