Beacon Timing and Wake Slots

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

foundations
math-foundations
calculation-audit
wifi-mobile
Ada ADA · CALCULATION AUDIT

Beacon Timing and Wake Slots

A battery sensor that rarely receives commands can raise its DTIM period from 1 to 3, letting it sleep about 307 ms between mandatory beacon wakeups instead of about 102.4 ms — and at fleet scale, a building of 300 Wi-Fi sensors reporting every 30 seconds needs Target Wake Time so those wakeups do not become a thundering herd on the channel. This audit asks the question both examples invite: do the DTIM sleep-window numbers and the TWT fleet-spacing math actually check out as stated?

Companion to the chapter Wi-Fi Power Consumption — every number here comes from that chapter.

Ada: Wi-Fi power claims are timing physics plus a state ledger. The chapter already gives enough numbers to check the DTIM timing and the fleet-scheduling intuition without inventing current values.

  • A beacon interval of 100 TU uses 1 TU = 1.024 ms, so 100 x 1.024 ms = 102.4 ms.
  • With DTIM = 3, the mandatory DTIM wake interval is 3 x 102.4 ms = 307.2 ms.
  • Compared with DTIM = 1, the interval ratio is 307.2 / 102.4 = 3.0, and the extra possible downlink delay is 307.2 - 102.4 = 204.8 ms.
  • For the TWT fleet example, 300 sensors reporting every 30 s average 300 / 30 = 10 reports per second if the AP spreads them evenly.
  • The same schedule is 30 s / 300 = 0.1 s = 100 ms between planned sensor wake starts.
  • Battery charge still needs measured state currents. For one 30 s reporting cycle, charge per report (mAh) = (I_awake x t_awake + I_sleep x (30 - t_awake)) / 3600, with current in mA and time in seconds.

The audit conclusion is bounded: DTIM 3 really is a 307.2 ms timing window, and a 300-sensor TWT fleet can be spread at roughly 100 ms spacing across a 30 s cadence. Those numbers support the timing claim, not a battery-life claim, until the active current, sleep current, retry time, service-period duration, and fallback behavior are measured on the real device.

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