How much battery does BLE use?

Bluetooth Low Energy was designed for low power, but the radio only saves energy when it is idle. Every advertisement, every scan window and every connection event switches it on. How much battery BLE uses is therefore a question about duty cycle: the share of time the radio is transmitting or listening, and at what power.

That is why the platforms describe energy in terms of choices rather than figures. Apple’s Core Bluetooth guide tells developers to minimise how much an app uses the radio, because radio usage has an adverse effect on an iOS device’s battery life, and because the radio is shared with Wi-Fi, Bluetooth Classic and other apps. Android’s documentation attaches power trade-offs to its scan, advertising and connection settings. Any battery figure for BLE is really a figure for one set of those choices on one device.

Scanning keeps the receiver listening; Apple’s guide notes that a scanning central uses its radio until the app tells it to stop. Android’s guide says plainly that scanning is battery-intensive and gives two rules: stop scanning as soon as you find the device you want, and never scan on a loop, always with a time limit.

Android’s scan modes make the trade-off explicit:

• SCAN_MODE_LOW_POWER is the default and consumes the least power. Android enforces it when the scanning app is not in the foreground.
• SCAN_MODE_BALANCED returns results at a rate that trades scan frequency against power.
• SCAN_MODE_LOW_LATENCY scans with the highest duty cycle and is recommended only while the app is in the foreground.
• SCAN_MODE_OPPORTUNISTIC starts no scan of its own and receives results from other apps’ scans.

Apple gives the same advice: scan only when you need to, call stopScan once you have found the peripheral, and avoid the option that reports every duplicate advertisement unless the use case needs it, since it can hurt battery life and performance.

A device that wants to be found has to advertise, and the advertising interval sets the cost. Android’s ADVERTISE_MODE_LOW_POWER is the default and preferred mode because it consumes the least power, while ADVERTISE_MODE_LOW_LATENCY has the highest power consumption and should not be used for continuous background advertising.

Apple’s accessory guidelines show the trade-off for discovery: an accessory should first advertise at 20 ms for at least 30 seconds, then move to a longer interval, such as 152.5 ms or as long as 1285 ms. Apple notes that longer intervals usually mean longer discovery and connection times, but may lower power consumption.

Once two devices connect, they exchange packets in connection events, and the radio can idle between them. The connection interval sets how often events happen. Peripheral latency lets a peripheral save power by not responding at every event when it has no data to send, which Apple’s guidelines describe as a way for an accessory to conserve power.

Shorter intervals give lower latency and more throughput, and cost more energy. Android’s requestConnectionPriority exposes this as a choice: CONNECTION_PRIORITY_HIGH is for transferring large amounts of data quickly, after which the app should return to CONNECTION_PRIORITY_BALANCED to reduce energy use, while CONNECTION_PRIORITY_LOW_POWER requests reduced data rate parameters. Apple’s guidelines ask accessories to request a minimum interval of at least 15 ms, in multiples of 15 ms, with peripheral latency of no more than 30 connection intervals.

How data is sent matters too. Apple’s guidelines say Data Packet Length Extension, which raises the maximum data per packet from 27 to 251 bytes, improves radio efficiency and boosts battery life. Fewer, fuller packets mean less time on air for the same bytes. Apple also advises discovering only the services and characteristics an app needs, since full discovery costs battery.

Transmit power is a direct trade between range and energy: the Bluetooth SIG notes that higher transmit power increases power consumption. The LE Coded PHY reaches farther but keeps the radio on longer for each byte.

On a phone in a mesh, the biggest variable can be other people’s traffic. A phone that relays messages for its neighbours scans, connects and transmits more than one that only sends its own. Mesh software can bound that work. The Offline Protocol mesh SDK, for example, documents a relay battery threshold of 30% by default in v0.27.0, alongside retry and queue limits.

Because the answer depends on settings, hardware and OS behaviour, the reliable way to know is to measure:

1. Run the real workload, including discovery, idle periods and bursts of traffic, on the phones or boards you will ship.
2. Measure with the app in the foreground and in the background, since both platforms apply different rules there.
3. Change one parameter at a time, such as scan mode, advertising interval or connection priority, and compare.

Report the result with its settings. A battery figure without the scan mode, intervals, PHY and transmit power is not comparable with any other.