When 56% Smaller Means Fits vs Does Not Fit

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

When 56% Smaller Means Fits vs Does Not Fit

Hourly reporting from 10,000 sensors adds up to 87,600,000 messages a year, and the chapter prices that fleet at 64 bytes per JSON message versus 28 bytes in CBOR — a 56% reduction it calls a payload saving, not automatically a battery saving. LoRaWAN’s SF12 data rate caps a single uplink at just 51 bytes. This audit asks the question that ceiling invites: is the 56% CBOR saving just a smaller bill at fleet scale, or is it the difference between a payload that fits one SF12 frame and one that does not?

Companion to the chapter REST API Design Patterns — every number here comes from that chapter.

Ada: The chapter proves CBOR is 56% smaller than JSON — (64 - 28) / 64 = 0.5625 — and at fleet scale 87,600,000 x 64 = 5,606,400,000 bytes of JSON versus 87,600,000 x 28 = 2,452,800,000 bytes of CBOR, a 3.15 GB/year saving. Those check out. But a percentage hides the operational consequence, so let me test both payloads against the chapter’s own 51-byte SF12 LoRaWAN limit.

• JSON payload: 64 bytes > 51 bytes — over the SF12 window by 64 - 51 = 13 bytes. It does not fit in a single frame at the slowest, longest-range data rate.
• CBOR payload: 28 bytes ≤ 51 bytes — it fits, using 28 / 51 = 54.9% of the SF12 budget, leaving headroom for headers and future fields.

The audit conclusion is that the 56% reduction is not a cosmetic bandwidth saving here — at SF12 it is the difference between a payload that fits one uplink and one that must be dropped, fragmented, or forced to a shorter-range data rate. The byte diet only becomes an energy saving when airtime dominates, but it becomes a feasibility decision the moment the payload has to cross the smallest LoRaWAN window.

Every number above is taken from the chapter’s own material and re-derived step by step.