When 56% Smaller Means Fits vs Does Not Fit
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.
See the relationship before changing it
The figure reads from left to right. The blue card is encoded payload. The middle card applies this page's rule. The green card is sf12 payload use. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only encoded payload, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 28 bytes.
- 2
Name the relationship. use = payload bytes / 51-byte limit x 100
- 3
Substitute with units. 28 / 51 x 100 = 54.9%
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change encoded payload
Try Predict the direction of use = payload bytes / 51-byte limit x 100. Test another encoded payload, then compare sf12 payload use.
Observe A smaller encoding consumes less of the fixed SF12 payload window. Reset encoded payload to 28 and compare sf12 payload use.
Explain A smaller encoding consumes less of the fixed SF12 payload window.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
Ready: use the stated baseline inputs, then compare each displayed result.
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 by64 - 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, using28 / 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.