Many low-power wireless devices feel “not real-time enough”: a contact sensor reports slightly late, a sensor syncs periodically, BLE notifications jitter, or Zigbee and Thread end devices cannot always be awakened immediately.
This is usually not protocol laziness. It is the core trade-off of low-power wireless: a device that wants to save power cannot keep listening to the air all the time. If it does not listen all the time, wake windows, queues, and latency appear.
longer sleep -> lower power -> easier to miss immediate communication -> higher latency
more frequent wakeup -> lower latency -> higher airtime and power cost
Receiving Also Consumes Power
Transmit power gets attention, but receive power matters too. For battery devices, keeping the receiver on to listen to the air can drain power quickly.
Low-power devices reduce:
- Long receive listening
- Frequent scanning or advertising
- Unnecessary retries and wakeups
They often do not stay online continuously. They wake up, check, communicate, and return to sleep.
Duty Cycle Drives Average Power
Duty cycle roughly means the fraction of time a device is awake and working.
average power ~= sleep power * sleep time + active power * wake time
Sleep power is low, but radio activity, MCU work, sensor sampling, and cryptographic processing cost more during wake time. If wakeups are frequent, average power rises quickly.
That is why reporting once per second and once per minute can produce completely different battery life.
Connection Intervals and Wake Windows Decide Responsiveness
In BLE connections, both sides meet at connection events. A shorter connection interval improves responsiveness, but the device wakes more often. A longer interval saves power, but data waits for the next event.
Zigbee and Thread sleepy end devices face similar constraints. A sleepy end device cannot receive like an always-on router. The network may need to buffer messages until the end device wakes and polls.
Low-power “online” often means periodically reachable, not continuously listening.
Power Saving Changes Debug Evidence
Low-power behavior is often mistaken for link failure.
Examples:
- A command does not take effect immediately because the device has not woken up
- BLE notification jitter comes from connection interval, slave latency, or event scheduling
- A Zigbee end device does not respond briefly because of parent buffering and polling cycle
- NB-IoT latency comes from PSM, eDRX, paging, and report policy
These look like packet loss or stalls, but the cause may be power scheduling.
Low Latency, Long Battery Life, and High Reliability Cannot All Be Maxed Out
Low-power wireless often wants three things:
- Long battery life
- Immediate command response
- Reliable data transfer
They cannot all be maximized.
Lower latency means more frequent wakeups or longer receive windows, increasing power. Longer battery life means longer sleep and queued commands. Higher reliability often needs acknowledgements, retries, and redundancy, adding airtime and energy.
Parameters are not simply “smaller is better” or “larger is better.” They must match the workload.
Different Workloads Need Different Trade-Offs
Periodic sensors, locks, remotes, presence detection, and OTA download need different low-power behavior.
- Temperature sensors may tolerate reports every tens of seconds or minutes
- Door locks need lower latency and stronger acknowledgement
- Leak sensors can sleep long but must report quickly after triggering
- OTA download temporarily sacrifices power for continuous transfer
- Presence detection continuously trades responsiveness against battery life
Do not judge only by default protocol parameters. Define the application timing first, then derive connection interval, wake period, retry policy, and buffering strategy.
Engineering Judgments
For low-power wireless issues, ask:
- Is the device always powered or battery powered?
- Does it listen continuously or wake periodically?
- What end-to-end latency does the application allow?
- Should commands be buffered until the next wakeup?
- Do retries and acknowledgements increase wake time significantly?
- Does the strategy change at low battery?
Low-power wireless is not merely weaker real-time wireless. It redistributes online presence, latency, reliability, and battery life. Understanding sleep, wakeup, and latency gives the right entry point for many “why does the device not respond immediately?” problems.
Continue Reading
- Why Bandwidth, Rate, and Throughput Are Not the Same in Wireless: why throughput and wake time must be considered together
- Why Wireless Communication Cannot Avoid Channels, Interference, and Retries: how retries amplify latency and energy cost in low-power devices