A field team has a real problem to settle: Why does DTIM 3 give only 2.19 times the runtime? They must decide what happens before they change dtim count on the device. Predict the direction first.
See the relationship first
The figure reads from left to right. The blue card is dtim count. The middle card uses this page's rule. The green card is beacon interval. Follow the arrows: set the input, use the rule, then read the result and its unit.
The audit later on checks more than one number. Here, the added model uses the baseline named below and holds every other chapter value fixed. That sentence bridges the fixtures, so the numbers do not change without a reason.
Derive the baseline in four moves
- 1
Name the input. The chapter baseline for dtim count is 3.
- 2
Name the rule. 100 x 1,024 μs = 102.4 ms DTIM 3: T = 3 x 102.4 = 307.2 ms duty = 3 / 307.2 = 0.0097656 = 0.9766% Iavg = 0.0097656(150) + 0.9902344(1) = 2.4551 mA runtime = 2,000 / 2.4551 = 814.64 h = 33.94 days 33.94 / 15.53 = 2.185 times DTIM 1
- 3
Put in the chapter value. Set dtim count to 3. The page rule gives beacon interval as 102.4 ms.
- 4
Read the result. Keep ms next to the value. Use it only within the limits on this page.
Predict, then change dtim count
Try Predict what happens to beacon interval. Move one control, calculate, then check your idea.
Observe The wake term shrinks with DTIM count, but the sleep term approaches one whole milliamp and sets a ceiling near 83.3 days. Reset to 3 and compare beacon interval.
Explain Only dtim count moves here. The other chapter values stay fixed.
Check yourself
What should you do before you trust the result?
What does this small model leave out?
1. Start with the physical story
The station draws high current for a short check and low current for the rest of each interval. DTIM makes checks less frequent. It does not reduce either current, so the low sleep draw keeps accumulating between checks.
2. Name every algebra move
Convert Time UnitsMultiply 100 TU by 1,024 microseconds, then divide by 1,000 for milliseconds.
Apply DTIMMultiply the 102.4 ms beacon interval by the DTIM count.
Find dutyDivide the 3 ms wake by the whole wake period.
Weight both currentsMultiply each current by its fraction of time, then add.
Find runtimeDivide usable milliamp-hours by average milliamps.
3. Reproduce the chapter case
DTIM 3: T = 3 × 102.4 = 307.2 ms
duty = 3 / 307.2 = 0.0097656 = 0.9766%
Iavg = 0.0097656(150) + 0.9902344(1) = 2.4551 mA
runtime = 2,000 / 2.4551 = 814.64 h = 33.94 days
33.94 / 15.53 = 2.185 times DTIM 1
The beacon count triples, but runtime does not, because the fixed 1 mA sleep term takes a larger share of the average.
4. Try one real input
TryMove DTIM count from 1 toward 10. Watch the wake period grow while runtime gains flatten toward the sleep-current limit.
ObserveAt DTIM 3, average current is 2.456 mA and runtime is 33.93 days, only 2.185 times DTIM 1.
ExplainThe wake term shrinks with DTIM count, but the sleep term approaches one whole milliamp and sets a ceiling near 83.3 days.
This is a periodic wake-current ledger, not a field battery-life prediction.
- Traffic
- The 3 ms check is fixed; buffered data, multicast timing, retries, scans, association, and application work are omitted.
- Battery
- 2,000 mAh is treated as usable charge; temperature, ageing, conversion loss, cutoff, and self-discharge are omitted.
- Network
- A larger DTIM can increase latency or missed delivery and must match the access point and application.
Correct, not complete: this ledger does not choose a DTIM or guarantee runtime.
5. Use the result in the design
Use the ledger to form a power and latency test plan. Measure real wake duration and sleep current, then check queued traffic, retry behaviour, responsiveness, and missed-delivery recovery.
6. Record the evidence state
Record AP beacon and DTIM settings, firmware power mode, wake duration, active and sleep currents, traffic pattern, latency result, battery assumptions, measured runtime, and the retest trigger.
7. Check yourself
Why is DTIM 3 equal to 307.2 ms here?
Why is runtime not three times DTIM 1?
Does 33.93 days predict a deployed device?
This is a periodic wake-current ledger, not a field battery-life prediction.
- Traffic
- The 3 ms check is fixed; buffered data, multicast timing, retries, scans, association, and application work are omitted.
- Battery
- 2,000 mAh is treated as usable charge; temperature, ageing, conversion loss, cutoff, and self-discharge are omitted.
- Network
- A larger DTIM can increase latency or missed delivery and must match the access point and application.
Correct, not complete: this ledger does not choose a DTIM or guarantee runtime.
Eddie guides