BLE vs WiFi power consumption: mA data & battery life

Updated Aug 17, 2026

Contents

The gap between BLE and WiFi power draw isn't a spec-sheet footnote, it's the difference between a sensor that runs three years on a coin cell and one that needs a battery swap every month. Most teams pick a radio based on throughput needs and discover the power cost only after field deployment.

The mechanism behind the gap is duty cycling, not raw radio efficiency, and understanding it changes how you design the whole product. Here's what the published datasheet figures for nRF52 and ESP32 hardware actually show.

BLE vs WiFi power: The order-of-magnitude difference

Bluetooth Low Energy idle current sits in the low-microamp range on dedicated BLE SoCs, while Wi-Fi radios stay in the tens-of-milliamps range even in their lowest powered-up sleep mode. Nordic's nRF52810 draws 1.5 µA in System ON with RTC running, which is what keeps time between advertising events, while the ESP32's modem-sleep mode (CPU powered, radio off) draws 20-68 mA depending on clock speed and core count (Nordic nRF52810 product brief; Espressif ESP32 Series Datasheet v5.3, Table 4-2).

That's four orders of magnitude apart, and it compounds fast: a Wi-Fi sensor checking in every few seconds can drain a coin cell in days, while a BLE peripheral running the same duty cycle lasts years.

The challenge most IoT teams hit is picking a radio before quantifying that math against their own workload. The measured figures below, pulled from each vendor's own datasheet, are the numbers to check before you commit to a network.

Measured power draw: nRF52 vs ESP32 benchmark data

The nRF52810 stays in the low-microamp range between advertising windows, with transmit current spiking for only a few milliseconds per beacon: 4.6 mA TX at 0 dBm (7.0 mA at +4 dBm), 4.6 mA RX, and 1.5 µA in System ON with RTC running between events (Nordic nRF52810 product brief).

The ESP32, running full Wi-Fi association, holds transmit current at 180-240 mA depending on data rate (240 mA for 802.11b DSSS, dropping to 180 mA for 802.11n OFDM), and its lowest powered-up sleep state, modem-sleep, still draws 20-68 mA, never single digits, since the CPU stays active even with the radio off (Espressif ESP32 Series Datasheet v5.3, Tables 4-2 and 5-4).

Run those numbers against a real mAh budget and the gap gets physical fast. A 220 mAh CR2032 coin cell on duty-cycled Bluetooth Low Energy firmware can outlast the same cell on Wi-Fi by well over a year, simply because the ESP32's floor (tens of mA, CPU always on) is orders of magnitude above the nRF52810's floor (fractions of a µA).

How BLE achieves microamp-level power consumption

Bluetooth Low Energy hits microamp-level power consumption through aggressive duty cycling: the radio wakes only for advertising interval or connection interval windows, then drops back to sleep current for the rest of the cycle. Per the Bluetooth SIG Core Specification, advertising intervals range from 20 ms to 10.24 seconds, and connection intervals from 7.5 ms to 4 seconds, giving firmware engineers direct control over the battery-versus-latency trade-off.

A GATT profile batches reads into short transactions, so transmit power spikes for milliseconds rather than staying on. Wi-Fi devices, by contrast, keep the radio running longer to maintain association and handle beacon frames, which is why BLE wins any use case where devices sleep more than they talk.

BLE connection lifecycle: Advertising to GATT

BLE's connection lifecycle moves through four power states: standby, advertising, initiating, and connected, and each one draws current differently.

During advertising, the radio broadcasts on channels 37 to 39 at the configured advertising interval, then drops back to sleep current until the next window opens (All About Circuits - Breaking Down the BLE Link Layer). Once a central device connects, Bluetooth Low Energy shifts into GATT profile exchange, where characteristics get read or written on the connection interval schedule.

The nRF52810's 4.6 mA TX current at 0 dBm applies whether that transmission is an advertising packet or a connected-state notification, but a connected device transmits far more often per second than an advertiser. That's why tuning connection interval matters as much as advertising interval choice for battery-constrained IoT designs.

Why WiFi draws more current: 802.11 power profile

IEEE 802.11 was engineered to move data fast, not to sleep efficiently, and that trade-off shows up before a single payload byte moves: a station has to scan, authenticate, and associate with an access point, then maintain that association with periodic keepalive traffic, all before the first application byte moves.

Scan, authenticate, associate, then negotiate a DHCP lease: on a cold boot, that sequence commonly holds a Wi-Fi radio in an active, high-current state for several seconds before the first application byte moves, longer if the access point is busy or DHCP is slow to respond.

Bluetooth Low Energy (BLE) was designed around the opposite priority. According to Bluetooth SIG's core specification, a BLE device completes advertising-to-GATT connection setup in single-digit milliseconds, using a fraction of the current a WiFi association requires.

WPA3 adds its SAE handshake on top of WiFi's association cost, a security tax BLE's lightweight pairing never has to pay. Layer on a full TCP/IP stack, retransmissions, keepalives, and cloud-sync ACKs, and WiFi's transmit power budget for a connected sensor node ends up dwarfing BLE's by an order of magnitude.

State	ESP32 (Wi-Fi)	Nordic nRF52810 (BLE)
TX (radio active)	180-240 mA	4.6-7.0 mA
RX	95-100 mA	4.6 mA
Lowest powered-up sleep, radio off	20-68 mA (modem-sleep, CPU on)	1.5 µA (System ON + RTC)
Deepest sleep, no wake timer needed	10 µA (RTC + memory only)	0.3 µA (System OFF)

Sourced from the Espressif ESP32 Series Datasheet v5.3 and the Nordic nRF52810 product brief. The gap isn't unique to BLE as a protocol, either: the ESP32's own Bluetooth/BLE radio draws 130 mA TX, close to its Wi-Fi figures, because it shares silicon and power infrastructure with the Wi-Fi radio rather than being purpose-built for microamp idle current the way a dedicated BLE SoC is. Chip design, not just protocol choice, decides how much of BLE's theoretical power advantage you actually get.

This is the real engineering challenge behind battery-powered, wireless IoT. Different connectivity technology choices, whether BLE, WiFi, or something else entirely, enable very different power outcomes, and WiFi's convenience comes bundled with a tax that duty cycling alone cannot fully claw back.

When to choose BLE vs WiFi: Range, throughput, power trade-offs

Choose Bluetooth Low Energy when using battery-powered sensors that report small payloads over short range, and choose Wi-Fi wireless technology for devices that stream data continuously or sit on mains power. A coin cell battery, the CR2032, is the practical dividing line: BLE sensor tags routinely run one to two years on one, while a Wi-Fi equivalent drains the same cell in days.

Range and throughput invert the calculus. Wi-Fi covers 30-plus meters indoors at speeds upward of 100 Mbps, where BLE's GATT profile tops out around 1-2 Mbps, built for kilobit-scale telemetry rather than video or firmware blobs over the air (GSMArena Wi-Fi Definition).

Gateway architecture matters more than either radio spec alone. BLE devices need a hub to reach the cloud, adding an always-on gateway power budget the sensor itself never carries. Wi-Fi devices skip that hop but pay for it in transmit power and WPA3 handshake overhead per session.

Use this decision tree: if the device is battery-only, sends small data bursts, and can tolerate a gateway, choose BLE. If it's mains-powered, needs direct cloud connectivity, or moves larger payloads, Wi-Fi enables faster throughput at the cost of battery life. The BLE vs Wi-Fi choice ultimately comes down to matching the power and throughput required to the actual deployment, not the other way around.

BLE mesh, thread, and WiFi HaLow: Alternatives worth weighing

BLE Mesh, Thread, and WiFi HaLow extend the two-protocol choice when a single-hop network can't cover the building. BLE Mesh relays advertising packets node to node, but each hop adds sleep-current overhead, so a five-hop mesh drains faster than a star topology with a strong gateway.

Thread, built on 802.15.4, offers lower multi-hop cost than BLE Mesh through IPv6 routing, though it demands a border router. WiFi HaLow (802.11ah) trades Wi-Fi's throughput for sub-1GHz range and lower transmit power, closer to Bluetooth Low Energy sleep profiles than classic Wi-Fi (802.11 Networks Corp). Netguru evaluates all three during IoT architecture reviews, weighing gateway cost against battery replacement cycles before recommending one.

BLE Mesh relay/normal nodes draw ~6-15 mA continuously due to radio in RX mode, unlike low-power nodes (Nordic Semiconductor DevZone (engineering Q&A), 2023)

FAQ: BLE and WiFi power consumption

How many mA does BLE consume during advertising?

BLE advertising typically pulls single-digit milliamps for a few milliseconds per event (4.6-7.0 mA on Nordic's nRF52810, depending on TX power), then drops to low-microamp sleep current between advertising windows, around 1.5 µA with the RTC still running to time the next event (Nordic nRF52810 product brief). Check your advertising interval setting first, since a 1-second interval versus a 100 ms interval changes average draw by an order of magnitude.

How long does a BLE device battery last on a coin cell?

A Bluetooth Low Energy sensor on a 220 mAh CR2032 coin cell commonly runs two to five years, depending on connection interval and GATT profile notification frequency (Multiple sources: Argenox, Nordic Semiconductor, MDPI). Check your notification rate before sizing the cell — a conservative interval is what gets you to the multi-year end of that range.

What is WiFi's typical power consumption in IoT sensors?

Wi-Fi IoT sensors draw 180-240 mA while transmitting on an ESP32, and even their deepest sleep state, with only the RTC timer and memory powered, still needs 10 µA, since the radio has to fully re-associate on wake rather than resume from a low-power idle state the way BLE does (Espressif ESP32 Series Datasheet v5.3). That transmit current runs 25-50x higher than BLE's radio-on draw. Proceed with Wi-Fi only when devices sit near mains power or a rechargeable pack.

Does WiFi HaLow draw less power than BLE?

WiFi HaLow (802.11ah) uses less energy than classic Wi-Fi thanks to its sub-1 GHz band and Target Wake Time (TWT) scheduling, which lets a device negotiate a wake schedule with the access point instead of listening continuously. But it still runs a full TCP/IP and WPA3 security stack underneath, so BLE keeps the sleep-current edge for coin-cell devices. Try HaLow when you need Wi-Fi-class range with mesh gateway simplicity, not BLE's battery life.

How much power does BLE mesh add over point-to-point BLE?

BLE Mesh adds roughly 10-30% more average current than point-to-point BLE because every node relays advertising packets for its neighbors, and each relay hop adds latency on top of the power cost (Silicon Labs, Bluetooth Mesh network performance). The challenge compounds with hop count: a multi-hop mesh node burns meaningfully more current than a star-topology sensor talking straight to a gateway, since a relay node's radio spends more time in RX mode listening for packets to forward.

Can I reduce WiFi power consumption for battery-powered IoT?

Yes, stretching beacon and sleep intervals through 802.11 power-save mode and offloading WPA3 handshakes to a gateway cuts Wi-Fi's average draw substantially. Batching multiple sensor readings into a single wake-and-transmit window, rather than reconnecting for every reading, helps some teams shave milliamp-hours further. Check duty cycling settings on your Wi-Fi SoC first, since most of the savings come from sleeping longer, not transmitting less.

Get help choosing the right radio for your IoT product

Choosing between Bluetooth Low Energy and Wi-Fi is rarely a spec-sheet exercise once you factor in gateway architecture, battery replacement cost, and security overhead like WPA3 key rotation versus BLE pairing. A hybrid radio strategy often resolves this challenge better than picking one standard outright.

Getting from prototype to field deployment means matching the duty-cycling profile to your real connection interval and GATT profile requirements, not shipping with vendor defaults tuned for a generic use case.

Please talk to our team and we'll check your power budget together before you commit to a radio.