OTA & Lifecycle Management

OTA Updates in the Field: The Problem Nobody Talks About Until It's Too Late

Author: Srihari Maddula  •  Founder & Technical Lead, Eurth Techtronics Pvt Ltd

Category: OTA & Lifecycle Management  •  Estimated Reading Time: 18–20 minutes

Published: July 2026

Three months after deployment of a 120-node IoT network, the engineering team discovered a timing bug in the transmission scheduler. Under specific load conditions, nodes would collide on the shared RF channel, causing packet loss that cascaded into data gaps. The fix was 12 lines of firmware code. Review, test, and validation took two days.

The field update took eight days, two engineers, and travel across three districts. Because there was no OTA mechanism in the firmware. Each node had to be physically accessed, connected to a programmer, flashed, reconnected, and verified. Some nodes were mounted at 4 metres elevation. Some were in enclosures that required tools to open. Forty nodes were never updated because reaching them required coordinating with the farmer, and the farmer was unavailable during the harvest period.

This is the OTA story that nobody tells when they skip OTA development to hit a launch deadline. The bug is not the failure. The inability to fix the bug remotely is the failure. And it is a failure that was chosen at the architecture stage — six months earlier, in a sprint planning meeting where OTA was moved to Version 2.

Why OTA Gets Deferred — And Why That Decision Is Wrong

OTA gets deferred for legitimate-sounding reasons. It adds development time — typically 3 to 6 weeks for a robust implementation. It requires additional flash partitioning, which reduces available application space. It adds complexity to the bootloader, which is already a sensitive piece of code. It requires server-side infrastructure — a firmware distribution service, version management, rollout control.

All of these are real costs. None of them change the fundamental arithmetic: if you deploy hardware that cannot be updated remotely, you will eventually pay a cost in field visits that exceeds the saved development time by an order of magnitude. This is not a theoretical risk. It is a certainty. Every firmware has bugs. Every product has features that need modification based on field learning. The question is not whether you will need to update deployed firmware — you will. The question is whether you can do it without sending someone in a car.

The correct mental model is to think of OTA not as a feature but as infrastructure — the same category as power supply, clock, and reset logic. You do not defer power supply design to Version 2. OTA belongs in the same category.

The A/B Partition Architecture — Why It Is Non-Negotiable

The minimum viable OTA implementation uses a single firmware bank and overwrites it during an update. This is fast to implement and works in the lab. In the field, it is a reliability disaster. If power is interrupted during a flash write — which happens in agricultural and industrial environments with load shedding, unreliable solar backup, and vibration-induced connector breaks — the device is bricked. No firmware. No recovery path. Physical intervention required.

The A/B partition architecture maintains two complete firmware images in flash. The active image runs from partition A. An update writes to partition B, verifies the hash of the written image, sets a boot flag pointing to partition B, and reboots. If the new firmware boots and validates successfully, it becomes the new active partition. If it fails — if the boot validation check does not pass within a defined timeout — the bootloader falls back to partition A. The device is never in an unbootable state.

The flash cost of this approach is one additional firmware image worth of space — typically 256 KB to 512 KB depending on application size. On modern microcontrollers with 1 MB to 4 MB of internal flash, this cost is almost always acceptable. On resource-constrained devices with 128 KB flash, it is a genuine constraint that needs to be designed around — but it is a constraint that should be identified at the hardware selection stage, not discovered when OTA is being retrofitted.

Connectivity-Specific OTA: LoRa vs Cellular vs Wi-Fi

OTA complexity varies dramatically with the connectivity technology in use. Wi-Fi OTA is the simplest case — bandwidth is high, latency is low, and a 512 KB firmware image transfers in seconds. The implementation challenge is mostly in the bootloader and partition management logic, not in the transport layer.

Cellular OTA (NB-IoT, LTE-M, 4G with SIM) is straightforward in implementation but has cost implications. Transferring a 512 KB firmware image over cellular data costs money — not a lot per update, but across a 1,000-node fleet updated quarterly, it adds up. Delta OTA — transmitting only the difference between old and new firmware — reduces this cost significantly. Binary diff tools like bsdiff or detools can produce deltas that are 20 to 40 percent of the full image size for typical firmware changes.

LoRa OTA is the hardest case. The data rate of a LoRaWAN link at useful range is typically 250 bps to 5 kbps depending on spreading factor and bandwidth. A 256 KB firmware image at 1 kbps takes 2,048 seconds — over half an hour — to transfer, assuming perfect packet delivery. In practice, packet loss requires retransmission, and the multicast sessions required to update multiple nodes simultaneously add coordination complexity. The LoRaWAN FUOTA (Firmware Update Over The Air) standard addresses this, but its implementation requires support in both the device firmware and the network server, and it is genuinely complex to implement correctly.

This is a legitimate reason to prefer cellular over LoRa for deployments where firmware iteration frequency is expected to be high. The connectivity cost difference may be smaller than the operational saving from reliable remote updates.

Fleet Management: Beyond Pushing a Binary

At 10 devices, OTA is a manual operation. An engineer clicks a button, the device updates, the engineer verifies. At 500 devices across 50 customer deployments, OTA needs to be a managed process with staged rollout, success rate monitoring, automatic rollback triggers, and audit logging.

Staged rollout means updating a subset of devices first — 5 percent, then 20 percent, then the remainder — with monitoring between stages. If the 5 percent cohort shows elevated reboot rates or connectivity problems after the update, the rollout stops. The remaining 95 percent never receive the bad firmware. This is not a feature for scale-ups. This is a feature for the second deployment, because the second deployment is where you discover that your firmware behaves differently on hardware from a different production batch, or under a temperature range you did not test.

Audit logging — knowing which device is running which firmware version, when it was updated, and whether the update was successful — is essential for support operations. Without it, when a device starts behaving unexpectedly, you cannot determine whether the behaviour change correlates with a firmware update, a hardware issue, or an environmental change. The log is the root cause analysis starting point.

The Conversation to Have Before You Write the First Line of Firmware

Every embedded product development should begin with an explicit OTA architecture decision. Not 'will we do OTA' — the answer is always yes. But: what connectivity will OTA use, what is the partition strategy, what is the rollback mechanism, what is the fleet management approach, and what is the server-side infrastructure.

These decisions constrain hardware selection (flash size, RAM for update buffers), bootloader design, application firmware layout, and cloud infrastructure. Making them at the beginning means they are incorporated into all subsequent decisions. Making them at Version 2 means retrofitting them into an architecture that was not designed for them — which is always more expensive, always more fragile, and always leaves a generation of deployed hardware permanently unupdatable.

THE RULE: Build OTA before you ship. Not after.

The field has no patience for 12 lines of code that require eight days to deploy.

© 2026 Eurth Techtronics Pvt Ltd  |  eurthtech.com  |  All rights reserved.