IllustrationSize a tracker update by computing payload bytes, including retransmits and block overhead, then dividing by the effective throughput you measure on your own network. A delta image cuts the bytes sent, but needs a rollback path. This guide gives the formulas, a worked example with hypothetical inputs, and a test plan.
A tracker on a narrow cellular link has a small update window and a small battery. A full image can take a long time to move and uses data on every unit. A delta image sends less, but it adds a patch step on the device. This guide gives you the formulas to size both, and the rollback and resume pieces that keep a bad update from bricking the unit. It focuses on the link and the data math. It contains no Duobay price and no measured result.
What do the primary sources say?
These are the five facts the rest of this guide builds on. Each row links to the original page and was read on October 31, 2026.
| Topic | What the source says | What it means for your design | Source |
|---|---|---|---|
| MCUboot test swap and revert | A test swap is reverted on the next reset unless the new image confirms itself. The design page says: "If this doesn’t happen, MCUboot will perform a “revert” swap during the next boot". | This is the rollback path that keeps a failed update from bricking the unit. | MCUboot design page, as of October 31, 2026 |
| MCUboot invalid image | The design page says: "If the image is invalid MCUboot erases its memory slot and starts to validate the other image." | A corrupt download is discarded and the bootloader falls back to the other image. | MCUboot design page, as of October 31, 2026 |
| LwM2M Firmware Update object | The registry entry says: "A LwM2M Client MUST support block-wise transfer [CoAP_Blockwise] if it implements the Firmware Update object." The object exposes State and Update Result resources. | Those two resources are a ready-made vocabulary for retry and resume state. | OMA LwM2M registry, object 5, as of October 31, 2026 |
| Heatshrink window size | The README says: "For embedded/low memory contexts, a `window_sz2` in the 8 to 10 range is probably a good default." | A compression library for low-memory targets. It can shrink a patch before transfer. The achieved ratio on your builds is not published. | Heatshrink README, as of October 31, 2026 |
| Zephyr DFU scope | The documentation says: "The DFU subsystem deals with image management, but not with the transport or management protocols themselves". | Transport, resume and delta logic are your team’s job. | Zephyr DFU documentation, as of October 31, 2026 |
How do you size one update?
Transfer time follows from the bytes you actually send and the throughput you actually get. Use the payload: the patch plus retransmits plus block overhead.
payload_bytes = S_delta × (1 + r) + O
transfer_time_s = payload_bytes × 8 / B
fleet_data_MB = payload_bytes × D / 1,000,000
fleet_cost = fleet_data_MB × P
full-image case: replace S_delta with S_full
worst case with retries: payload_bytes × (1 + K)Units: S_delta, S_full, O and payload_bytes are bytes. B is bits per second. r and K are unitless. D is a count. P is currency per MB, so fleet_cost is in the same currency. This sheet uses decimal megabytes (1 MB is 1,000,000 bytes). Match the unit your carrier bills in.
Worked example with hypothetical inputs
These inputs are invented to show the arithmetic. They are not measurements and not vendor figures. Replace every one of them.
- S_delta = 50,000 bytes (hypothetical)
- r = 0.10 (hypothetical)
- O = 5,000 bytes (hypothetical)
- B = 20,000 bits per second (hypothetical)
- D = 10,000 devices (hypothetical)
payload_bytes = 50,000 × 1.10 + 5,000 = 60,000 bytes. transfer_time_s = 60,000 × 8 / 20,000 = 24 seconds. fleet_data_MB = 60,000 × 10,000 / 1,000,000 = 600 MB. fleet_cost = 600 × P, where P is your own plan price. With one extra full attempt allowed (K = 1) the worst-case payload doubles to 120,000 bytes and the time to 48 seconds. Change B to a tenth of that value and the time grows tenfold, which shows why measuring B on your network comes first.
Inputs, and which are yours to replace
| Variable | Meaning | Status | What to do |
|---|---|---|---|
| S_full | Full image size, bytes | Your build output | Read it from your build artifact. |
| S_delta | Delta size, bytes | Your assumption | Measure it by diffing two real consecutive builds. The vendor sources here publish no ratio. |
| r | Retransmit fraction (0.10 means 10 percent extra bytes) | Your assumption | Measure it on a live network from your own transfer logs. |
| O | Per-block overhead summed over the transfer, bytes | Your assumption | Count headers per block times blocks, from a capture of your own transfer. |
| B | Effective throughput, bits per second | Your assumption | Vendor did not publish a figure we can cite here. Measure it on your board with your module on your network. |
| D | Devices in the fleet | Your assumption | Your plan. |
| P | Price per MB of cellular data | Your assumption | Take it from your own data plan. This article cites no carrier price. |
| K | Retry budget: extra full attempts you allow per update | Your decision | Set from battery and data limits, and record the reason. |
How do rollback, retry and resume fit together?
Keep the roles separate. The bootloader decides which image runs. Your firmware owns the download and its state. The server decides which patch to offer.
- Rollback: use a test swap so an image that never confirms is reverted on the next reset (MCUboot design page, as of October 31, 2026).
- Corrupt download: verify before the swap. MCUboot erases an invalid image slot and validates the other image.
- Resume: store the transfer progress where a reset will not erase it, and report it through State and Update Result if you use the LwM2M Firmware Update object (OMA LwM2M registry, as of October 31, 2026).
- Block-wise transfer: the LwM2M object requires it, so plan the block size and its overhead into O.
- Flash layout for a test swap: plan room for the running image and the new image, plus the bootloader. Confirm it on your real part.
On storage, heatshrink targets low-memory devices and suggests a window_sz2 of 8 to 10 as a default (Heatshrink README, as of October 31, 2026). Whether it helps your patch, and what RAM it needs on your chip, is a test for your board.
What are the common traps?
These follow from the sourced facts above. They come from engineering reasoning. None describes an incident at any company.
- Treating a delta as free of risk. A delta only applies to the exact base build it was made from. If part of the fleet runs a different build, a patch can fail to apply. This follows from how a patch works. No incident is cited here. Track the running version per device before choosing which patch to send.
- Confirming too early. MCUboot reverts a test image unless it confirms itself. If the firmware confirms before the cellular stack and the cloud connection are proven, a build that cannot reconnect still survives the reset and the unit goes silent. Decide what "healthy" means before you write the confirm call.
- Counting only the download. The payload is the patch plus retransmits plus per-block overhead. A formula that uses the file size alone understates both time and data.
- Assuming the bootloader handles transport. Zephyr DFU handles image management. Transport and management protocols are left to your firmware. Resume, retries and delta decoding are yours to build and test.
- No room for a test swap. A test swap needs the new image and the running image both present in flash. Check the flash map early. A part that cannot hold two images forces a different design. This is arithmetic on your own flash layout.
- Retry loops that drain the battery. Without a retry budget, a unit with a weak link can keep downloading. Cap the attempts, and record the reason for the cap.
What should you test on your own board?
Vendor documentation does not give your delta ratio, your network throughput or your power cost. We have not measured these for you, and no result appears in this article. The pass line is set by you from your product requirements, and you record the basis for it.
| What to test | How to instrument or collect it | Raw data to record |
|---|---|---|
| Delta size on real builds | Build two consecutive releases, produce the patch with your chosen tool, and apply it on a bench unit. | Both build hashes, full size, patch size, patch tool and its settings, and whether the applied image verified. |
| Effective throughput | Log bytes acknowledged against time on the device during a real download over your target network, at more than one location. | Timestamps, byte counts, network type, signal readings your module reports, location and time of day. |
| Retransmissions | Count blocks sent versus blocks accepted in a transfer log from the server side and the device side. | Per-block sent and acknowledged counts, timeouts, and the cause of each retry if your stack reports one. |
| Power cost of a long download | Put a current meter on the battery rail for a whole download, from wake to sleep. | Current trace, duration, bytes moved, supply voltage, temperature. |
| Resume after a dropped session | Cut the link at several points during a transfer, including near the end and during the write to flash, then let it reconnect. | Where each cut happened, the State and Update Result values reported afterward, bytes re-sent, and whether the image verified. |
| Rollback | Ship a deliberately faulty image to a bench unit, and a second image that boots but never confirms. | Reset count, which image ran after each reset, and the time to recover. |
Set the pass line for each row before you run it, and write down why you chose it.
What should you decide before you commit?
- Which exact base builds are in the field, and can the server produce a patch for each one?
- What do we do with a unit whose base build is unknown or too old: send the full image, or hold it?
- What does "healthy" mean at the moment of confirm, and who agreed to it?
- Where do we keep the retry and resume state, and is it written to flash or lost at reset?
- How many extra full attempts does the retry budget K allow, and what limits it?
- Is the patch compressed before transfer, and does the device have the RAM to decode it?
- Does the flash map hold two images plus the bootloader, and have we confirmed that on the real part?
- Which numbers in our sizing sheet are measured on our board, and which are guesses?
- Who pays for the data of a failed update, and where does that line appear in the data budget?
Questions about tracker updates
Is a delta update always smaller than a full image?
Not necessarily. The vendor sources here publish no ratio. Measure the patch between two real consecutive builds of your own firmware, and keep the full image path for units whose base build does not match.
How fast can I push an update over LTE-M or NB-IoT?
Vendor did not publish a figure we can cite here. Measure the effective throughput on your board with your module on your network, then use it as B in the formula in this article.
What stops a bad update from bricking the tracker?
With MCUboot, a test swap is reverted on the next reset unless the new image confirms itself, and an invalid image is erased in favor of the other one (MCUboot design page, as of October 31, 2026). You still have to decide when the firmware confirms.
Does the bootloader download the image for me?
No. Zephyr DFU handles image management. Transport and management protocols are left to your firmware (Zephyr DFU documentation, as of October 31, 2026). Your team builds transport, resume and delta logic.
Can Duobay size the update path for my tracker?
We do not publish prices. Gate 0 Feasibility produces a system architecture document and a risk register (see how Feasibility works). Tell us about your tracker and we will explain how it works.
If you want help planning the update path for a cellular tracker, tell us about your tracker. You can also read how we approach LTE and GNSS tracker development.
Sources
All pages accessed October 31, 2026. Documentation changes, so re-read it before you decide.
- MCUboot, design: https://docs.mcuboot.com/design.html (accessed 2026-10-31)
- Open Mobile Alliance, LwM2M registry, Firmware Update object: https://raw.githubusercontent.com/OpenMobileAlliance/lwm2m-registry/prod/5.xml (accessed 2026-10-31)
- Heatshrink README: https://github.com/atomicobject/heatshrink (accessed 2026-10-31)
- Zephyr Project, DFU: https://docs.zephyrproject.org/latest/services/device_mgmt/dfu.html (accessed 2026-10-31)
Planning a tracker? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →