Wake-Up Energy Calculation Audit

Wake-Up Energy Calculation Audit

Ada keeps the RTT budget, radio power, and rounding separate in the wake-up energy claim

foundations
math-foundations
http
energy
intermediate
Ada ADA · CALCULATION AUDIT

Wake-Up Energy Calculation Audit

The chapter models a cellular device waking 96 times a day with a 100 ms RTT: HTTP/1.1 spends 33.6 s/day on handshakes versus HTTP/3’s 9.6 s/day, which at 1.11 W radio power is 37.3 against 10.7 J/day — a 71% saving. This audit checks the wake-up energy numbers and bounds what the 71% actually claims: connection overhead, not whole-device battery life.

Companion to the chapter Modern HTTP for IoT — every number here comes from that chapter.

The physics link is the radio active window. Keep the RTT arithmetic separate from the power conversion, then round once at the end so the claimed saving is traceable.

See the relationship before changing it

The figure reads from left to right. The blue card is handshake rtt count. The middle card applies this page's rule. The green card is daily handshake energy. 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 handshake rtt count, so the numeric fixture does not switch without explanation.

Handshake RTT count changes daily handshake energy An input card leads through the rule energy = 96 wakes/day x RTT count x 0.100 s x 1.11 W to the daily handshake energy result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. More round trips keep the cellular radio active longer on every daily wake.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 3.5 RTT.

  2. 2

    Name the relationship. energy = 96 wakes/day x RTT count x 0.100 s x 1.11 W

  3. 3

    Substitute with units. 96 x 3.5 x 0.100 x 1.11 = 37.30 J/day

  4. 4

    Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change handshake rtt count

Try Predict the direction of energy = 96 wakes/day x RTT count x 0.100 s x 1.11 W. Test another handshake rtt count, then compare daily handshake energy.

3.5 RTT
Chapter baseline
Daily handshake energy

Observe More round trips keep the cellular radio active longer on every daily wake. Reset handshake rtt count to 3.5 and compare daily handshake energy.

Explain More round trips keep the cellular radio active longer on every daily wake.

Check yourself

What should you do before trusting a moved-control result?
Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only handshake rtt count moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only handshake rtt count. It is not a field prediction.

TryBegin Check derivation at 96 wake-ups per day, a 100 ms RTT, and 1.11 W of active radio power.
ObserveHandshake airtime falls from 33.6 to 9.6 s/day, and the connection-energy readout consequently drops from 37.3 to 10.7 J/day.
ExplainHTTP/3 removes repeated handshake round trips, so fewer 100 ms radio-active intervals produce the 71% connection-overhead saving.

1. Convert the existing RTT example into seconds

The chapter uses 96 wake cycles per day, a 100 ms RTT, and multipliers of 3.5, 2.5, and 1.0:

HTTP/1.1 = 96 x 3.5 x 0.100 s = 33.6 s/day
HTTP/2 = 96 x 2.5 x 0.100 s = 24.0 s/day
HTTP/3 0-RTT = 96 x 1.0 x 0.100 s = 9.6 s/day

2. Convert current and voltage into radio power before multiplying

The existing 300 mA and 3.7 V values give:

P = I x V = 0.300 A x 3.7 V = 1.11 W

Using that full value, the daily handshake energy is:

HTTP/1.1 = 33.6 s x 1.11 W = 37.296 J/day -> 37.3 J/day
HTTP/2 = 24.0 s x 1.11 W = 26.64 J/day -> 26.6 J/day
HTTP/3 0-RTT = 9.6 s x 1.11 W = 10.656 J/day -> 10.7 J/day

3. Compute the reduction from unrounded joules

For the HTTP/1.1 to HTTP/3 comparison:

(37.296 - 10.656) / 37.296 = 0.714285... = 71.4%

The displayed 71% saving is therefore a rounded connection-overhead result. It is not a whole-device battery-life claim until receive windows, retries, payload airtime, sleep current, and failed resumptions are added to the same ledger.

Technical boundaries
Payload transfer, application work, retries, carrier tail states, server delay, signal variation, regulator loss, and battery ageing are not included in this wake-up ledger.

Work the audit first, then check the displayed derivation.

Every number above is taken from this chapter's own worked example and re-derived step by step.