How to Achieve 5-Year Battery Life with Silicon Labs EFR32BG26
Your energy budget is 5.4 µA. That’s the entire conversation.
A CR2032 coin cell holds about 235 mAh. Spread that over 5 years and you get 5.4 microamps of average current to play with. Every GPIO left floating, every peripheral you forgot to gate, every extra millisecond of radio time eats into that budget. The EFR32BG26 datasheet says 1.2 µA in EM2 sleep. Your board will probably measure 1.5 µA. That 0.3 µA gap burns 6% of your entire 5-year budget before you’ve transmitted a single byte.
This guide walks through a real power budget for a BLE sensor on the BG26, line by line, and shows you exactly where your microamps go.
The Reference Design: What We’re Building
To make this concrete, here’s the device we’re optimizing:
- BLE advertising: 5-second interval, connectable undirected, 3 channels
- BLE connection: 1 connection per minute, 20-byte notify, then disconnect
- Sensor read: I2C temperature sensor, 10 ms active read, once per minute
- Sleep: EM2 with LFXO and full RAM retention for the remaining ~99.7% of the time
This profile fits asset trackers, environmental monitors, and medical wearables. If your use case is close to this, the numbers will translate directly. If it’s different, the method still applies; just swap in your own duty cycles.
Here’s what a typical 1-minute cycle looks like:
┌─────────────────────────────────────────────────────────┐
│ TYPICAL 1-MINUTE CYCLE │
├─────────────────────────────────────────────────────────┤
│ EM2 SLEEP ADV EM2 ADV EM2 CONN EM2 │
│ (1.5 µA) EVENT SLEEP EVENT SLEEP EVENT SLEEP│
│ │
│ ───────────┐ ┌─┐ ┌──────┐ ┌─┐ ┌─────┐ ┌──┐ ┌── │
│ 1.5 µA │ │ │ │ │ │ │ │ │ │ │ │ │
│ ───────────┘ │ │ │ │ │ │ │ │ │ │ │ │
│ ~8 mA ────┘ └──┘ └──┘ └──┘ └──┘ └──┘ │
│ │
│ ◄──────── ~55 seconds sleeping ────────► (99.7%) │
│ ◄── ~300 ms total active ──► ( 0.3%) │
└─────────────────────────────────────────────────────────┘The device spends 99.7% of its life asleep, so sleep current dominates everything.
BG26 Power Modes: What Actually Matters
The BG26 has 5 energy modes. You only need to care deeply about one.
┌────────┬────────────┬─────────────────────────┬──────────────────┐
│ Mode │ Typ. Curr. │ Peripherals Available │ Wake Source │
├────────┼────────────┼─────────────────────────┼──────────────────┤
│ EM0 │ 27 µA/MHz │ All │ — (active) │
│ EM1 │ 18 µA/MHz │ All (CPU halted) │ Any interrupt │
│ EM2 │ 1.2 µA │ RTCC, LFXO, IADC, GPIO │ RTCC, GPIO, BLE │
│ EM3 │ 1.0 µA │ GPIO, CRYOTIMER │ GPIO, CRYOTIMER │
│ EM4 │ 0.1 µA │ GPIO wakeup only │ GPIO pin, reset │
└────────┴────────────┴─────────────────────────┴──────────────────┘EM2 is the deepest mode that keeps the BLE stack’s timekeeping alive. The RTCC runs off the LFXO, RAM stays retained, and the radio can wake on schedule. EM3 and EM4 are deeper but kill the BLE timing; you’d need a full reconnection after every wake, which costs far more energy than the sleep savings.
If you’re migrating from the EFR32BG24, the BG26 brings two specific EM2 improvements:
- A more efficient DC-DC converter at low loads
- Lower EM2 current when using the LFRCO instead of the LFXO
Neither happens automatically. You have to explicitly select the DC-DC regulator path and configure LFRCO if your application’s timing tolerance allows it. Check the BG26 datasheet’s electrical characteristics table (not the BG24 one; the numbers differ by revision).
The most common mistake: leaving a peripheral clock enabled when entering EM2. The IADC, a USART, even an unused timer, each adds tenths of a microamp that show up on your bench but not in your mental model.
Building the BG26 Power Budget, Line by Line
Every row is a calculable, measurable piece of your energy budget.
┌──────────────────────┬──────────┬──────────┬──────────┬──────────────┐
│ State │ Current │ Duration │ Freq │ Avg. Current │
│ │ (mA) │ (ms) │ (/min) │ (µA) │
├──────────────────────┼──────────┼──────────┼──────────┼──────────────┤
│ EM2 Sleep │ 0.0015 │ — │ — │ 1.50 │
│ BLE Advertising │ 8.0 │ 2.5 │ 12 │ 4.00 │
│ BLE Connection Event │ 9.5 │ 3.0 │ 1 │ 0.48 │
│ I2C Sensor Read │ 4.0 │ 10.0 │ 1 │ 0.67 │
│ DC-DC Overhead │ — │ — │ — │ 0.15 │
├──────────────────────┼──────────┼──────────┼──────────┼──────────────┤
│ TOTAL AVERAGE │ │ │ │ ~4.80 µA │
├──────────────────────┼──────────┼──────────┼──────────┼──────────────┤
│ CR2032 (235 mAh) │ │ │ │ ~5.6 years │
└──────────────────────┴──────────┴──────────┴──────────┴──────────────┘Here’s how the math works for each line.
EM2 sleep is the baseline. The 1.5 µA figure includes LFXO running, full RAM retention, and typical board-level leakage on a well-designed PCB. Datasheet says 1.2 µA; real boards land at 1.4 to 1.6 µA.
BLE advertising is probably your biggest surprise. At a 5-second interval, you get 12 advertising events per minute. Each event transmits on 3 channels, totaling about 2.5 ms at ~8 mA. The average current contribution: (8.0 × 2.5 × 12) / 60,000 = 4.0 µA. That’s 83% of your active-mode budget.
BLE connection events are cheaper because they happen less often. One connection per minute, 3 ms at 9.5 mA: (9.5 × 3.0 × 1) / 60,000 = 0.48 µA.
Sensor reads are brief. 10 ms of I2C traffic at 4 mA, once per minute: (4.0 × 10.0 × 1) / 60,000 = 0.67 µA.
DC-DC overhead is a fixed penalty for using the switching regulator. On the BG26, it’s roughly 0.15 µA during sleep. Worth it, because the DC-DC saves you more than that during active transmit bursts.
Total: ~4.8 µA average, giving you ~5.6 years on a 235 mAh CR2032. That’s a 12% margin above the 5-year target, which you’ll want because battery self-discharge eats 1 to 2% per year.
Firmware Optimization Checklist
Sleep Configuration
Every microamp of sleep current costs you 0.7 years of battery life.
- Set all unused GPIOs to disabled (not floating, not input). Floating pins can oscillate and draw current. Use
GPIO_PinModeSet()withgpioModeDisabled. - Audit pull-up and pull-down resistors. Each enabled internal pull burns roughly 0.1 µA. If the pin isn’t connected to anything, disable the pull.
- Decide between LFXO and LFRCO. LFXO gives you ±20 ppm accuracy for BLE timing but costs ~0.3 µA more than LFRCO. If your application tolerates ±500 ppm (many advertising-only designs do), LFRCO saves you real current.
- Disable VCOM (the virtual COM port) in production firmware. It keeps the debug UART bridge powered, adding 100+ µA. Set
SL_BOARD_ENABLE_VCOMto 0. - Gate the debug interface. If you’re using SWD, configure
EMU_EM23PERNORETAINCTRLto disable debug access in EM2 for production builds.
BLE Stack Configuration
The radio is where you spend or save the most energy.
- Advertising interval: Every halving of the interval doubles the advertising power cost. Going from 5 seconds to 2.5 seconds adds 4 µA, almost your entire remaining budget.
- Connection interval and slave latency: Set the connection interval as long as your latency requirement allows. A 1-second connection interval with slave latency of 4 means the BG26 only wakes every 4 seconds during a connection. That cuts connection event overhead by 75%.
- TX power: 0 dBm is the sweet spot for most indoor applications. Stepping to +6 dBm nearly doubles transmit current (from ~8 mA to ~14 mA) for roughly 4x the range. Only do it if you’ve measured and confirmed you need it.
- PHY selection: Use LE 2M PHY when the central supports it. It halves the on-air time for each packet, cutting your connection event current contribution roughly in half.
Peripheral Management
- Explicitly disable peripheral clocks before entering EM2 using
CMU_ClockEnable(cmuClock_xxx, false). The BLE stack doesn’t do this for peripherals it doesn’t own. - Power-gate your I2C sensor through a GPIO-controlled load switch. Just idling the I2C bus still draws whatever quiescent current the sensor pulls. A MOSFET or load switch with <0.1 µA leakage costs almost nothing.
- If you need periodic ADC sampling, use the IADC in EM2 single-shot mode with hardware triggering from the RTCC. This avoids waking the CPU entirely for a measurement.
If you’re integrating the BG26 into a product that also uses Hubble’s satellite or terrestrial connectivity, the device integration guide covers how to structure firmware for multi-radio coordination without blowing your power budget.
Hardware Problems That Firmware Can’t Fix
A few board-level choices will cap your battery life regardless of how good your firmware is.
DC-DC vs. LDO: The BG26’s internal DC-DC converter is more efficient than the LDO above about 1.8 V input. For a CR2032 (starting at 3.0 V, ending around 2.0 V), the DC-DC wins for the entire discharge curve. Make sure your decoupling follows Silicon Labs’ reference layout exactly; sloppy inductor placement kills DC-DC efficiency.
Leakage paths: Flux residue between power and ground traces can create leakage currents that exceed your sleep budget. Clean your boards. If you’re seeing EM2 current above 2.0 µA on a prototype, suspect the board before the firmware.
Battery self-discharge: An Energizer CR2032 loses about 1% per year at room temperature. Over 5 years, that’s 5% of your capacity gone. Your 5.6-year projection becomes ~5.3 years after accounting for this.
External components: Check your pull-up resistor values. A 10 kΩ pull-up to 3.0 V on an I2C line burns 300 µA when the line is low. Use 100 kΩ or higher if your bus speed allows it. And remove any indicator LEDs from production hardware, or ensure they can’t be accidentally enabled.
Measuring and Validating Your Power Budget
Don’t trust calculations alone. Measure.
Simplicity Studio Energy Profiler is your first tool. Connect to the dev kit’s AEM (Advanced Energy Monitor) and capture a full duty cycle. You should see flat EM2 sleep at ~1.5 µA, sharp 8 mA spikes for advertising, and slightly taller 9.5 mA spikes for connection events. If your baseline is above 2 µA, something’s still on that shouldn’t be.
Energy Profiler has a resolution of about 0.1 µA, which is fine for validating EM2 current. For higher-resolution measurements, place a 10 Ω shunt resistor in series with the battery and measure voltage across it with a scope or Keithley source meter.
Common pitfalls that wreck your measurements:
- Debug mode keeps the CPU in EM1 instead of EM2. Always test power in release builds with the debugger disconnected.
- VCOM enabled (mentioned above, but it’s the #1 cause of “why is my sleep current 500 µA?”).
- The dev kit’s onboard sensors and LEDs draw current that your custom board won’t. Measure on your actual hardware, not just the dev kit.
For designs that also report data through the Hubble terrestrial network, you can validate uplink timing independently of BLE by checking the power profile during transmission windows.
5 Highest-Impact Actions
- Set advertising interval to the longest your product allows. Going from 1 second to 5 seconds saves ~16 µA.
- Audit every GPIO. Set unused ones to disabled, remove unnecessary pulls. On one prototype, this alone dropped EM2 current by 0.4 µA.
- Use the DC-DC converter and follow the reference layout precisely. The efficiency gain pays for itself across the entire discharge curve.
- Disable VCOM and debug access in production firmware. This is the single easiest fix and can save 100+ µA.
- Measure on real hardware with a release build. Your power budget should be a living document: update each line with measured values as you go.
The BG26 silicon can hit 5 years on a coin cell. The hard part is making sure nothing else on the board or in the firmware wastes the budget it gives you. Build the table, measure each line, and you’ll know exactly where your microamps go.
Hubble Network enables BLE devices like these to connect directly from satellite, extending your ultra-low-power design’s reach without adding ground infrastructure. See how it works →