Where the 89% Saving and the 772-Day Battery Come From

Where the 89% Saving and the 772-Day Battery Come From

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

foundations
math-foundations
calculation-audit
coap
Ada ADA · CALCULATION AUDIT

Where the 89% Saving and the 772-Day Battery Come From

The chapter quotes two figures a reviewer must defend: CoAP Observe cuts monitoring traffic by about 89%, and a polling sensor lasts about 772 days on an 18650 cell. Both are reconstructable from the chapter’s own 44-byte and 28-byte messages and its 3000 mAh battery. This audit carries each end to end to show exactly where the 89% saving and the 772-day battery come from.

Companion to the chapter CoAP Observe Server Push — every number here comes from that chapter.

Try

The chapter quotes two figures a reviewer must defend: CoAP Observe cuts monitoring traffic by about 89% , and a polling sensor lasts about 772 days on an 18650 cell. Calculate this case.

Observe

This audit carries each end to end to show exactly where the 89% saving and the 772-day battery come from. Check shows this.

Explain

The audit conclusion is that the two figures measure the same lever from two directions: Observe removes about nine of every ten messages, and since radio energy is proportional to messages sent, that same reduction is what turns a two-year polling battery into a shelf-life-limited one. The design meaning is that the saving is real only while the resource changes slowly -- thebenefit shrinks as notification frequency approaches poll frequency. Check confirms it.

See the relationship before changing it

The figure reads from left to right. The blue input is observe notifications. The middle card names the page’s rule. The green output is traffic saving. The arrow matters: change the input, apply the rule once, then read the result with its unit.

Observe Notifications changes traffic saving A three-part teaching diagram connects observe notifications, the rule saving = (63,360 - (44 + 28 x notifications)) / 63,360 x 100, and traffic saving. INPUT Observe notifications APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrow. More notifications make Observe approach the polling traffic.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 240 notifications/day.

  2. 2

    Name the relationship. saving = (63,360 - (44 + 28 x notifications)) / 63,360 x 100

  3. 3

    Substitute with units. (63,360 - 6,764) / 63,360 x 100 = 89.32%

  4. 4

    Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.

Predict, then change observe notifications

Try Predict how traffic saving responds when observe notifications moves. Calculate observe notifications; compare traffic saving with that prediction.

240 notifications/day
Chapter baseline
Traffic saving

Observe Return to 240 notifications/day. Recheck traffic saving with observe notifications at its chapter value.

Explain More notifications make Observe approach the polling traffic.

Check yourself

What should you do before trusting a moved-slider result?
Answer: Predict its direction, apply the displayed relationship, keep the units, and compare the reset value with the chapter’s worked baseline.
What does this small model leave out?
Answer: Only observe notifications moves here. The traffic saving calculation excludes field effects listed below.

Honesty note. The traffic saving result holds observe notifications as the only changing input. It is not a field prediction.

Technical boundaries

The fixed inputs for “Where the 89% Saving and the 772-Day Battery Come From” omit notification loss, re-registration, DTLS, radio receive windows, server state cost, battery ageing, or changing event frequency; “Where the 89% Saving and the 772-Day Battery Come From” therefore reports only its named fixtures.

Ada: This chapter quotes two numbers a reviewer will be asked to defend: Observe cuts monitoring traffic by about 89%, and a polling sensor lasts about 772 days on an 18650 cell. Both are reconstructable from the chapter’s own message sizes and battery spec, so let me carry each through end to end.

  • Polling bandwidth (60 s interval, 24 h): 1440 exchanges x 44 bytes = 63360 bytes = 61.875 KB.
  • Observe bandwidth (1 registration + 240 notifications): 44 + 240 x 28 = 6764 bytes = 6.605 KB.
  • Saving: (63360 - 6764) / 63360 = 0.89324 = 89.3%, matching the chapter’s 89.3%.
  • Where “40 kJ” comes from: an 18650 at 3.7 V and 3000 mAh stores 3.7 V x 3.0 Ah x 3600 s = 39960 J, which the chapter rounds to 40 kJ.
  • Polling energy at 3.0 mJ per confirmed exchange, 17280 polls/day (every 5 s): 17280 x 3.0 = 51840 mJ = 51.84 J/day.
  • Battery life: 39960 / 51.84 = 770.8 days; using the rounded 40000 / 51.84 = 771.6, which is the chapter’s ~772 days.

The audit conclusion is that the two figures measure the same lever from two directions: Observe removes about nine of every ten messages, and since radio energy is proportional to messages sent, that same reduction is what turns a two-year polling battery into a shelf-life-limited one. The design meaning is that the saving is real only while the resource changes slowly – the 89% and the 772 days both assume roughly 10 notifications an hour, so a chattier resource must be rate-limited or the budget silently reverts to the polling case.

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