Beacon Timing and Wake Slots

Beacon Timing and Wake Slots

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

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.

See the relationship before changing it

The figure reads from left to right. The blue card is dtim period. The middle card applies this page's rule. The green card is mandatory wake interval. 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 dtim period, so the numeric fixture does not switch without explanation.

Walk the arrows. A larger DTIM period lengthens sleep between mandatory beacon checks.

Derive the baseline in four named moves

1. 1

   Name the input. The chapter baseline is 3 beacons.

2. 2

   Name the relationship. wake interval = DTIM period x 102.4 ms

3. 3

   Substitute with units. 3 x 102.4 ms = 307.2 ms

4. 4

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

Predict, then change dtim period

Try Predict the direction of wake interval = DTIM period x 102.4 ms. Test another dtim period, then compare mandatory wake interval.

DTIM period

3 beacons

Chapter baseline

Mandatory wake interval

Observe A larger DTIM period lengthens sleep between mandatory beacon checks. Reset dtim period to 3 and compare mandatory wake interval.

Explain A larger DTIM period lengthens sleep between mandatory beacon checks.

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 dtim period moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only dtim period. It is not a field prediction.

Try

Convert 100 TU using 1.024 ms/TU and apply DTIM = 3, then spread 300 TWT reporters evenly across a 30 s cadence.

Observe

The mandatory wake interval becomes 307.2 ms with up to 204.8 ms extra downlink wait; planned TWT starts can be spaced about 100 ms apart.

Explain

DTIM batches buffered downlink across multiple beacon intervals, while TWT assigns wake opportunities so the fleet need not contend or listen simultaneously.

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.

Technical boundaries: This timing-only schedule omits measured active and sleep currents, beacon drift, retry airtime, service-period length, AP buffering limits, fallback wakes, association maintenance, and battery conversion loss.

Ready: work the ledger before checking it.