How to Design Energy-Efficient OTA Updates for Battery-Powered IoT Devices

Shrinking the Payload with Delta Updates
Choosing Lightweight Compression and Protocols
My Personal Battle with Battery-Killing OTA Bugs
Implementing Resume-on-Failure and Low-Power Sleep States
Key Takeaways for Low-Power OTA Design
Frequently Asked Questions

Shrinking the Payload with Delta Updates

When you're designing battery-powered IoT devices, sending a full 1MB firmware image over-the-air is basically suicide for your battery life. The radio transceiver—whether it's Wi-Fi, cellular, or even BLE—is the biggest power hog on your board. If you keep that radio active for minutes downloading a massive binary file, you can kiss your multi-year battery life goals goodbye. The secret to keeping things efficient is simple: never send a single byte more than you absolutely have to. This is where delta updates, or differential updates, come into play. Instead of compiling a new firmware version and shipping the entire binary, you compare the old version running on the device with the new version on your server. This comparison generates a tiny patch file containing only the bytes that actually changed. On resource-constrained microcontrollers, your bootloader or update agent takes this small patch and applies it to the existing firmware partition to reconstruct the new application image. For example, a minor bug fix in your main loop might change only 5KB of code. Sending a 5KB delta patch instead of a 512KB full binary reduces your radio's active transmission time by roughly 99%. That translates directly to massive energy savings.

$A visual comparison flow diagram showing a full firmware update taking up major radio active time versus a delta patch update taking a fraction of the time, resulting in significant battery savings.$
A visual comparison flow diagram showing a full firmware update taking up major radio active time versus a delta patch update taking a fraction of the time, resulting in significant battery savings.

Choosing Lightweight Compression and Protocols

Reducing payload size is only half the battle. You also have to deal with how the data is packaged and transmitted over the air. Many developers default to standard HTTP/HTTPS over TCP for updates because it's familiar and easy to implement. However, TCP's heavy handshake process, packet acknowledgments, and connection maintenance overhead require your radio to stay awake longer than necessary. If your network architecture allows it, switching to UDP-based protocols like CoAP (Constrained Application Protocol) or MQTT-SN can make a huge difference. CoAP, in particular, supports block-wise transfers, which let you pull small chunks of the firmware patch step-by-step. Since CoAP runs on UDP, you avoid the heavy connection setup costs of TCP. Another key step is compression. While tools like gzip or LZMA are great for desktop operating systems, they require too much RAM for a modest microcontroller. Instead, look at lightweight compression algorithms like `heatshrink` or `FastLZ`. These algorithms are designed to run in environments with less than 10KB of available RAM. By compressing your delta patch before sending it, you squeeze down the transmission payload even further without taxing your device's processor during decompression.

A memory layout diagram of an IoT microcontroller flash memory, illustrating the active application partition, the staging partition for downloading patches, and the golden bootloader copy.

My Personal Battle with Battery-Killing OTA Bugs

Honestly, I've tried this myself on a commercial smart water meter project a few years back, and it was a massive wake-up call. We deployed fifty ESP32-based prototype nodes in a rural area, running on non-rechargeable lithium thionyl chloride batteries that were supposed to last five years. We set up standard HTTPS downloads for our firmware updates. The very first time we pushed a routine feature update, the connection was a bit spotty. Because of a poorly configured retry loop and the large 800KB uncompressed binary size, the nodes spent hours trying to download the file over a weak cellular signal. Some devices drained over 30% of their total battery capacity in just 48 hours! We had to manually drive out and replace those batteries. That painful lesson forced us to rebuild the entire system using lightweight CoAP block transfers and 30KB delta patches. After that refactor, our OTA runs took less than five seconds to complete, and the battery draw became completely negligible.

Implementing Resume-on-Failure and Low-Power Sleep States

In real-world IoT deployments, network connections are rarely stable. If your device loses its connection halfway through an update, you don't want to discard the data you already downloaded and start over. That would mean burning twice the energy for the same update. To prevent this, your firmware update agent must support resume-on-failure capabilities. Break your update binary into small, numbered blocks (e.g., 512 bytes each). As each block is downloaded and verified with a checksum, write it directly to your external flash or secondary staging partition, and save the progress offset to non-volatile memory. If the connection drops, the device can immediately go back to deep sleep. When the network becomes available again, the device simply requests the next block from the saved offset instead of starting from scratch. Speaking of sleep, you should never keep your CPU running at full clock speed while waiting for packets to arrive. If you're downloading an update over a slow network, configure your hardware to use light sleep states between packet receptions. Modern chips let you keep the radio subsystem active to listen for incoming packets while putting the main CPU core to sleep, saving precious microamps.

A state machine flowchart demonstrating the resume-on-failure download logic, highlighting state transitions between sleeping, receiving blocks, saving flash offsets, and error handling.

Key Takeaways for Low-Power OTA Design

Building an energy-efficient OTA update system requires a careful balance between processing power, flash memory limits, and radio usage. Here is a quick checklist to keep in mind for your next hardware design:

Pro-Tip: Always calculate the energy cost of running decompression on-device versus keeping the radio active longer. On most modern microcontrollers, running a lightweight decompression algorithm for a few extra milliseconds uses far less battery power than keeping a cellular or Wi-Fi radio active for even one extra second.

Use Delta Patches: Only transmit the changes, never the entire binary.
Pick UDP-Based Protocols: Swap out heavy TCP connections for CoAP or MQTT-SN where possible.
Stream and Write: Don't try to buffer the entire update in RAM; write blocks directly to flash.
Save Your Progress: Implement block-level resume-on-failure to handle connection drops gracefully.
Optimize Decompression: Use low-memory algorithms like `heatshrink` to minimize processing overhead.

Frequently Asked Questions

Q: Can I use delta updates on microcontrollers with highly limited flash memory?

Yes, you can. While delta updates do require some temporary storage to reconstruct the new firmware, you can use external SPI flash chips which are incredibly cheap and low-power. Alternatively, you can use a single-bank compression approach where the bootloader applies the patch on-the-fly, though this requires very robust safety checks to avoid bricking the device if power fails mid-update.

Q: Isn't UDP unsafe for sending critical firmware updates?

By itself, UDP doesn't guarantee packet delivery, which is why we run application-layer protocols like CoAP on top of it. CoAP handles packet verification, retransmissions, and block sequencing. For security, you should always sign your firmware binaries with cryptographic keys (like ECDSA) and use DTLS (Datagram Transport Layer Security) to encrypt the transmission.

Q: How much battery life can I actually save by switching to delta OTA?

On average, you can expect an energy reduction of 80% to 95% compared to standard, uncompressed full-image updates. The exact savings depend on your radio technology (cellular and Wi-Fi benefit the most, while low-power technologies like LoRaWAN show smaller absolute energy savings but benefit immensely from the reduced airtime).