Why Your BLE Module Draws 3x More Current Than the Datasheet Claims

You put your BLE module into deep sleep, connect the µA meter, and read 11 µA. The nRF52832 datasheet says 1.9 µA in system-off. You check your connections, re-read the datasheet, toggle every GPIO you can think of. The number barely moves. Your board looks clean and your firmware does exactly what the examples show.

Here’s the thing: the number you read is probably correct. The number you expected was never yours to expect.

That 1.9 µA figure comes from the SoC datasheet, measured on a bare die with specific conditions. Your module isn’t a bare die. It’s a tiny PCB with an LDO, a crystal, pull-up resistors, maybe an LED, and a handful of passives that each sip current all day long. None of them show up in the SoC datasheet. And when you stack 6 or 7 of these small draws together, you get the 3x (or 5x) multiplier that’s making you question your sanity.

The Datasheet You Read vs. The Datasheet That Applies

Most engineers start with the SoC datasheet. For the nRF52832, that’s Nordic’s product specification, Section 5, Electrical Specifications. It says 1.9 µA in system-off with RAM retained.

Then they pick a module (Raytac MDBT42Q, u-blox NINA-B3, Fanstel BT832, whatever) and mentally carry that 1.9 µA forward. Some module vendors even quote the SoC number in their marketing materials. The module’s own datasheet, if it has detailed power specs at all, often shows a single “typical” value at one operating point, with no breakdown.

The formula you actually need: Module current = SoC current + on-module overhead + interaction effects. That second and third term are where your missing microamps live.

Inherent Module Overhead: The Tax You Always Pay

Every module adds components around the SoC. Each one has a quiescent current cost. Here’s what’s sitting on that little PCB inside the shielding can.

On-module LDO. Most modules include a voltage regulator so you can feed them 3.3V (or up to 5V on some) even though the SoC runs at 1.8V internally. That LDO has a quiescent current of 1 to 10 µA depending on the part. Some modules use two regulators: one for the core, one for I/O. You’re paying this in every sleep state, always.

32.768 kHz crystal. The SoC datasheet’s lowest sleep number might assume the internal RC oscillator. But your module has a 32 kHz crystal soldered on, and it’s always connected. The crystal oscillator draws roughly 0.25 to 0.8 µA more than the RC path. Better timing accuracy, which you may or may not need.

Pull-up and pull-down resistors. Module vendors add pull resistors on UART RX, SPI CS, reset lines, and other pins to ensure safe default states. A 100 kΩ pull-up to 3.3V with the pin driven low burns 33 µA. Even with higher values (470 kΩ), four such resistors can add 1 to 3 µA depending on what your firmware does with those GPIOs.

RF matching network leakage. Usually under 0.5 µA, but nonzero. Always present.

Integrated sensors. Some combo modules (especially those from Bosch or with onboard accelerometers) include sensors with their own quiescent draw. A BMA400 accelerometer in low-power mode pulls 0.85 µA. If you didn’t know it was there, you’re measuring it and blaming your firmware.

LED indicators. A few modules have an LED connected to a GPIO that defaults high during boot or certain BLE states. If you haven’t explicitly driven that pin low, you could be leaking 100+ µA through a resistor-LED path. Obvious once you know to look, brutal if you don’t.

+---[ BLE MODULE ]-------------------------------------------+
|                                                             |
|   +--------+     +--------+     +---------+                 |
|   |  LDO   |---->|  SoC   |---->| RF/     |                 |
|   | 1-5 µA |     | 1.9 µA |     | Match   |                 |
|   +--------+     +---+----+     | 0.3 µA  |                 |
|                      |          +---------+                 |
|   +--------+    +----+----+     +---------+                 |
|   | 32 kHz |    | Pull-up |     |  LED    |                 |
|   | XTAL   |    | Network |     | (if on) |                 |
|   | 0.5 µA |    | 1-3 µA  |     | ~100 µA |                 |
|   +--------+    +---------+     +---------+                 |
|                                                             |
+-------------------------------------------------------------+
  VIN ─────────────────────────────────────────────> GND

Default Configurations That Waste BLE Idle Current

These are the draws you can eliminate with firmware changes, but they’re easy to miss because the defaults seem reasonable.

UART enabled by default. Many modules ship with UART active for DFU or AT-command interfaces. The UART peripheral on an nRF52, when clocked, can consume 0.5 to 1 mA (yes, milliamps). Even if you’re not sending data, if the peripheral is initialized and the clock is running, you’re paying for it. Disable it explicitly after boot if you don’t need it.

DC/DC converter not enabled. The nRF52 has an internal DC/DC buck converter that’s significantly more efficient than its internal LDO, but it requires an external inductor on specific pins. Your module almost certainly has that inductor. The firmware just doesn’t flip the switch by default. Enabling the DC/DC (one register write: NRF_POWER->DCDCEN = 1) can save 1 to 2 µA in sleep and significantly more during active/radio operation. If you’re working with the Hubble device SDK, check the power configuration examples in the reference apps.

GPIO defaults fighting module pull resistors. The SoC boots with most GPIOs configured as disconnected inputs. If the module has a 100 kΩ pull-up on one of those pins, the input buffer may oscillate or the pin may settle at a voltage that causes shoot-through in the input stage. Configure every GPIO explicitly: drive it to match the pull, or set it as input with a matching internal pull.

Unused peripherals left clocked. SPI, I2C, ADC, SAADC, PWM: if you initialized any of these during development and forgot to uninitialize them before sleep, they’re still drawing clock power. On the nRF52, each active peripheral can add 0.5 to 1.5 µA depending on clock source.

HFCLK left running. After a radio event, the high-frequency crystal oscillator (HFXO) may stay on if your firmware doesn’t explicitly stop it. This alone can cost hundreds of µA. The SoftDevice handles this for you in most cases, but if you’re running bare-metal, it’s on you.

PCB and System-Level Mistakes That Compound the Problem

The third layer sits on your board, not the module. But it interacts with the module’s internals in ways that inflate your measurement.

Floating module pins. That 20-pin module has pins you’re not using. Without internal pulls or external configuration, those pins can float at mid-rail and draw dynamic switching current. On CMOS inputs, this can be 0.5 to 2 µA per pin.

External pull-ups fighting internal pull-downs. You added a 10 kΩ pull-up on a pin that the module already pulls down internally with 13 kΩ. Congratulations, you’ve built a voltage divider that continuously conducts ~140 µA. Check the module schematic (if the vendor provides one) before adding external passives.

Decoupling cap leakage. Usually minor, but if you put cheap X5R or Y5V ceramic caps on the module’s power rail, their DC leakage at operating voltage can add 0.1 to 0.5 µA per cap. With 4 or 5 caps, it’s measurable.

Measurement errors that look like real current. An oversized shunt resistor can cause supply voltage droop under transient loads. That droop triggers brown-out detection loops, which inflate your average reading. A multimeter in µA mode averages over time and hides brief mA-level spikes that distort the mean. Use a Nordic PPK2 or similar tool that captures both the baseline and transients.

The Compounding Effect: No Single Villain

Here’s the full stack for a realistic nRF52832-based module scenario:

No single row looks outrageous. You wouldn’t file a bug report over 0.6 µA from a crystal. But the stack takes you from “coin cell lasts 5 years” to “coin cell lasts 11 months.” That’s the difference between a viable product and a warranty nightmare.

Three Tiers of Fixes, Matched to Your Constraints

Tier 1: Firmware changes (free, today). Enable the DC/DC converter. Disable UART after boot. Uninitialize every peripheral you’re not actively using. Configure every GPIO to a known, low-current state that matches the module’s pull resistors. Stop the HFCLK after radio events. This typically saves 2 to 5 µA and costs you an afternoon. If you’re building on the Hubble platform, the device integration timing guide covers how to manage active vs. sleep windows for minimal current draw.

Tier 2: Hardware tweaks (next board spin). Depopulate or disconnect the module’s LED. Swap pull-resistor values on module pins you can access. Add proper enable-pin control so you can power-gate the module entirely when it’s not needed. Terminate every unused module pin correctly. Budget 2 to 8 µA in savings depending on how many issues your current board has.

Tier 3: Bare SoC redesign. If you need to hit the SoC datasheet number, you need to be the SoC datasheet test setup. That means placing the bare die on your own PCB, choosing your own LDO (or running directly from battery), controlling every pull resistor, and taking on the RF matching and certification yourself. You get maximum control, but it takes maximum effort. Sometimes it’s the only way to hit a sub-3 µA power budget for a 10-year battery life target.

Most teams should exhaust Tier 1 before even thinking about Tier 3.

Building This Into Your Next Power Budget

The 3x gap isn’t a defect. It’s the cost of convenience, and module vendors aren’t hiding anything (mostly). They’re making tradeoffs for broad compatibility: wider voltage input, safe default pin states, factory testability.

Account for those tradeoffs in your power budget from day one. Don’t start with the SoC datasheet number. Start with the module datasheet number, then add your own board’s contribution. If the module doesn’t publish a sleep current figure, measure it yourself on an eval board before you commit to a schematic.

And if the number still doesn’t work, you know exactly where to look: the LDO you can’t remove, the pull-ups you can reconfigure, the UART you forgot to shut off, and the DC/DC switch you never flipped.

Hubble Network enables direct-to-satellite connectivity for BLE devices—so you can obsess over your power budget knowing your link layer scales without adding RF complexity. See how it works →