SEGGER emCompress and emCompress-ToGo for Indian IoT…

Every Indian IoT product team that ships a device with a cellular modem, NB-IoT, LTE-M, Cat-1, hits the same uncomfortable conversation on the third or fourth firmware release after launch. The field team needs a patch rolled out to 50,000 deployed devices. The full firmware image is 900 KB. Over NB-IoT, 900 KB per device takes several minutes of radio time and costs a measurable amount of rupees per unit in cellular data charges. Multiplied across the fleet, an OTA campaign turns into a meaningful line item in the operations budget and a multi-day rolling window during which the field is partially upgraded and partially not. The mechanical fix is obvious, compress the image, and ship deltas instead of full binaries: and the SEGGER library that implements both halves of the fix is emCompress and its binary-delta sibling emCompress-ToGo. This post walks through how Indian product teams use them, where they fit alongside the embOS OTA bootloader pattern, and what the practical integration looks like. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we support this workflow from library licensing through production rollout across India.

The Indian cellular OTA problem, stated plainly

The constraints that push Indian product teams toward compression and delta updates are not exotic. They are the standard cellular-IoT constraints amplified by Indian tariff structures and deployment geography.

Bandwidth cost. NB-IoT and LTE-M tariffs in India are typically priced per megabyte against a monthly allotment. A 1 MB full firmware image consumes a meaningful fraction of a month’s data budget for a constrained device. Multiply that across a fleet and OTA becomes visible in the cellular OPEX line.
Radio time and power. A cellular modem transmitting at full power for minutes is a battery event. For a solar-powered asset tracker or a battery-powered smart meter, a monthly full-image OTA is the biggest power consumer on the device, larger than the daily telemetry uploads combined. Shrinking the OTA payload directly extends battery life.
Transfer reliability. An NB-IoT link in a warehouse basement in a tier-3 Indian town may be up for a few seconds and down for longer. A 1 MB transfer across an intermittent link fails and restarts repeatedly. A 50 KB delta is often small enough to land in a single window.
Fleet coordination. A 72-hour rolling upgrade across a fleet with partial completion is a support headache. A 30-minute rolling upgrade across the same fleet is a support non-event. The fleet-management software is the same either way; what changes is the payload size.
BLE-based OTA from a dealer mobile app. The Indian two-wheeler and three-wheeler EV programmes that push controller firmware to vehicles via the dealer’s service-bay mobile app over Bluetooth Low Energy hit exactly the same constraint, a full image over BLE at typical throughput takes minutes, and the dealer’s customer is waiting. Shrinking the image to a delta cuts the bay time from minutes to seconds.

The corrective engineering action in every case is the same: compress the image on the host side at release time, decompress on the target, and, where possible, ship only the difference between the current image and the new one.

emCompress: the general-purpose compression library

emCompress is SEGGER’s embedded compression library. Its design point is a tightly-written LZSS / LZ4-family compressor and decompressor that runs on the host side at release time and on the target side during OTA apply. Key properties for Indian product teams evaluating it against open-source alternatives:

Target footprint is small. emCompress decompression runs comfortably on a Cortex-M0+ with a few kilobytes of RAM for the decompression buffer. It does not require a file system, an RTOS, or a dynamic memory allocator. It is built to fit in the OTA slot of a constrained device’s bootloader without pushing the bootloader past its flash budget.
Compression ratios on firmware binaries are in the 40-60% range. A 900 KB firmware image typically compresses to 400-500 KB, a meaningful reduction for a cellular transfer even before you consider deltas.
Per-product commercial licence is royalty-free. Once the licence is paid, every unit shipped carries the library without per-unit royalties. Indian product teams costing a BOM at high production volume can treat the licence as a one-time engineering cost rather than a per-unit tariff.
Commercial support contract. When something breaks in the field and the compressed image on one specific device does not decompress correctly, the support line is a phone call to SEGGER with an engineer on the other end, not a GitHub issue that waits for volunteer triage.

emCompress alone, the compression-only mode, is the baseline any Indian team should start with. It does not require any tooling changes beyond adding the compressor step at release time and the decompressor call in the OTA apply path. The savings are immediate and the risk is low.

emCompress-ToGo: the binary-delta variant

The next lever is delta updates: instead of shipping the full new image (even compressed), ship the difference between the old image and the new image, and have the target reconstruct the new image by applying the delta to its current image. This is the problem emCompress-ToGo solves.

Delta generation is a host-side operation. The OEM’s release engineer runs emCompress-ToGo’s command-line tool with the previous firmware binary and the new firmware binary as inputs, and the tool produces a delta file. For a typical incremental release, bug fixes, parameter updates, a new calibration table, the delta is 5-15% of the full image size. A 900 KB image’s delta is typically in the 50-150 KB range.
Delta application is a target-side operation. The target’s OTA code downloads the delta, applies it to the currently-running image (typically reading from the running bank of a dual-bank flash layout and writing to the inactive bank), and the result is the new image in the inactive bank. The bootloader then verifies the signature on the new image, see the companion emSecure post for the signature-verification step, and swaps banks on the next reset.
Reconstruction is deterministic and idempotent. Applying the same delta to the same source image always produces the same target image, byte for byte. This matters for regulated categories where the compliance reviewer wants to prove that the image on the device after OTA is identical to the image the release engineer signed.
Fallback path for devices on older firmware. When a device is too far behind the release train, it missed several intermediate deltas, the OTA server detects this from the device’s reported version and falls back to a full compressed image (plain emCompress) for that device. The same OTA apply path handles both cases because the delta and the full-image are wrapped in the same transport.

The combined effect on the cellular bill and the radio-on time is dramatic. A full 900 KB image shrinks to a 60 KB delta, a reduction of roughly 93%. The NB-IoT transfer window that previously took several minutes now lands in well under a minute. Across a fleet of 50,000 devices the cellular data charge for the campaign drops by the same proportion.

Where emCompress and emCompress-ToGo fit in the SEGGER stack

emCompress and emCompress-ToGo are the payload layer of the OTA pattern. The full commercial-grade Indian cellular IoT OTA stack has several layers above and below:

The bootloader and dual-bank apply path. Use the embOS bootloader and dual-bank OTA reference as the architectural starting point. The bootloader handles bank selection, signature verification, and the swap-and-revert safety net for a failed boot.
Signature verification on the reconstructed image. After the delta is applied and the new image is assembled in the inactive bank, the bootloader runs emSecure-RSA or emSecure-ECDSA against the reconstructed image to verify that it was signed by the OEM’s release key. The compression and delta encoding are orthogonal to the signing, you sign the plaintext image on the release side, then compress or delta-encode it for transport, and the target verifies the signature on the decompressed, reconstructed image.
Secure transport of the delta to the device. The delta is shipped from the OEM’s OTA service to the device over a TLS 1.3 link, typically the same emNet + emSSL stack used for MQTT telemetry to AWS IoT Mumbai or Azure IoT Central India. The cloud origin is the OEM’s OTA service, not a public CDN.
Root-of-trust provisioning at the factory. The device identity and the public key that the bootloader uses to verify the image signature are provisioned at the Indian contract manufacturer via Flasher Secure and the Flasher Secure Server, covered in the Flasher Secure post for Indian EMS partners.

The whole stack, bootloader, signature verification, compression, delta encoding, TLS transport, cloud OTA service, secure provisioning, is a single coherent architecture where each layer is a SEGGER library with a commercial support contract behind it.

Indian product programmes where the savings are largest

Not every product needs delta OTA. The programmes where Indian teams see the largest operational improvement from emCompress-ToGo are:

Smart-meter fleets on NB-IoT. A smart-meter fleet of tens of thousands of units deployed across an Indian discom’s service area, receiving monthly firmware patches over NB-IoT, is the canonical use case. Full-image OTA is infeasible in terms of cellular OPEX and upgrade window; delta OTA is routine.
Asset tracking on LTE-M or Cat-1. Indian logistics and industrial asset trackers deployed on trucks, containers, and industrial equipment across the country, receiving firmware updates while in transit, benefit directly from the shorter transfer time and the reduced radio power budget.
Two-wheeler and three-wheeler EV controllers. Pune and Bengaluru EV teams pushing controller firmware updates through the dealer network’s service-bay app over BLE cut the bay time from minutes to seconds. The dealer’s customer-experience metrics move in the right direction.
Industrial sensors over a gateway aggregation pattern. Chennai and Pune industrial-IoT OEMs pushing firmware to thousands of deployed Modbus-RTU sensors via a gateway that relays OTA payloads to the downstream sensors, covered in the emModbus industrial-automation post, use emCompress-ToGo to keep the gateway’s aggregate upload to the cloud small and the downstream RS-485 transfer fast.
Bandwidth-constrained field-service updates in general. Any Indian programme where the update link is expensive or slow, satellite relays, UHF radio links, long-range LoRa downlinks, benefits from the same 85-95% reduction in transfer size.

Working with GSAS on the rollout

emCompress and emCompress-ToGo are the kind of libraries where the architectural decision, plain compression or full delta-encoding, where to slot the apply step into the bootloader, how to coordinate with the fleet-management service, is the hard part, and the actual C code is the easy part. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH. Our engineering team works with Indian product teams from the first architecture review through licensing, integration, factory bring-up, and the first live OTA campaign. Teams across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, and Pune reach us when the cellular OPEX line in the operations plan starts to hurt. The fix is almost always an afternoon of architecture work followed by a few weeks of integration, and a cellular bill that drops by an order of magnitude on the next release.