How delta chunking compresses a 200MB payload into 18MB over LoRa + satellite. Field data from 3 rural deployments.
When your only link to a device is a 960 kilobit-per-second radio channel - or a LoRa frame measured in hundreds of bytes - shipping a full application binary every time you fix one line of code is simply not an option. At daedalus we solve this with SISR (Sporadic Incremental Stream Rebuild): instead of re-sending the whole image, we break the binary into chunks, identify the ones that changed, and transmit only those.
Delta delivery is not a new idea, and the industry data backs it up. Delta patches for typical maintenance and security updates represent roughly 5% to 20% of the full image size, cutting cellular data consumption by 80% to 95% per update. On Android fleets, delta updates have reduced payload size by up to 90% compared with full images. The pattern is consistent everywhere a fleet of devices runs mostly unchanged code.
Classical deltas are computed between two specific builds: they work only if the device sits exactly on the known starting build. A device that skipped versions, enrolled fresh, or came back from repair needs the full package - and that coordination overhead often eats the savings. SISR is chunk-addressed (content-addressed storage), so an update only transmits the modified chunks, regardless of how many versions a device has skipped.
We applied it to a 200MB diagnostic application deployed on Raspberry Pi gateways at three rural clinics. Over a 960kbps link, the full binary took roughly 28 minutes in ideal conditions. The SISR delta - the changed chunks compressed - came in at about 18MB, a ~91% reduction, arriving in under three minutes and surviving intermittent connectivity via resumable chunk transfer.
That is the same order of magnitude the downstream ecosystem reports: Canonical measured 60.5% bandwidth reduction on Dell Edge 3000 gateways and 65.4% on Rigado Cascade 500 gateways using snap deltas, and automotive suppliers routinely hit compression ratios of 5:1 to 10:1 on ECU binaries.
Three properties matter on a 960kbps channel. First, chunk-level resumption: a dropped LoRa window only re-sends the missing chunk, not the whole payload. Second, rollback: because chunks are content-addressed, the device keeps the previous chunk set and can revert against a corrupted update. Third, local verification: every chunk is SHA-256 addressed and Ed25519 signed before it is trusted.
Across the three deployments, the median update-payload reduction was 90%, worst case 71% (a major model replacement), best case 96% (a one-line patch to the analytics module). All three rotated updates over the same ~960kbps radio without a single full re-download.