The MCU datasheet says 5 microamps in sleep mode. The battery has 620 mAh. Quick math: 14 years. So why is the device dead after 11 months? Because the MCU is the least of your problems. We've spent a decade learning where the microamps actually go — and how to get them back.

The sleep current audit that changes everything

We do this exercise with every new hardware design. Write down every component and its sleep current. Not the datasheet typical — the actual worst case.

MCU: 5 microamps. Voltage regulator quiescent current: 45 microamps. Radio module deep sleep: 3 microamps. Sensor leakage: 8 microamps. That 100k pull-up resistor to 3.3V? 33 microamps, just sitting there. The power LED you left connected? 0.5 microamps reverse leakage. PCB contamination in a humid environment? 1-10 microamps between traces.

Add it up. Your "5 microamp" system is drawing 60+. That's why the battery dies in a year.

Every microamp counts at the system level. We've had projects where removing a single pull-up resistor added four months of battery life.

The regulator is the 80/20

If you do one thing to improve battery life, change the voltage regulator. A generic LDO with 50 microamp quiescent current will consume more power during sleep than everything else on the board combined.

The TPS62840 from TI: 60 nanoamp quiescent. The MAX38640A from Analog: 330 nanoamp. Dropping from 50 microamps to 60 nanoamps on the regulator alone can double or triple your battery life.

For coin-cell products, we often skip the regulator entirely. Most modern MCUs — nRF52, STM32L4, EFR32 — run down to 1.7V. A CR2032 is usable down to about 2.0V. Run directly from the cell. Zero regulator loss.

The exception: if you have 1.8V-only components (some SPI flash chips, certain sensors). Then you need a regulator for that domain. Use a load switch to power it only during active periods.

Firmware as a power state machine

Don't sprinkle sleep() calls around your code. Design the entire application as an explicit state machine with defined power states.

Deep Sleep: RTC only, everything else off. This is where the device spends 99.9% of its life. Sensing: MCU + sensor on, radio off. Read the sensor, compute the payload. Transmitting: MCU + radio on, sensor off. Send the data. Maintenance: everything on, for diagnostics and OTA.

Each state has a defined current draw, entry condition, exit condition, and maximum duration. The firmware's only job is to get back to Deep Sleep as fast as possible.

The biggest optimization: pre-compute your transmit payload during the sensing phase. When the radio wakes, it should be able to fire immediately. Every millisecond the radio is on but not transmitting is wasted energy.

When batteries aren't enough: energy harvesting

Some deployments can't afford battery replacement. Structural health sensors on bridges. Soil monitors in remote farmland. For these, we add energy harvesting.

Solar is the most practical: a 50x50mm cell gives 100-200mW in direct sunlight. Thermal energy generators produce around 30 microwatts per square centimeter from a 10-degree gradient. Vibration harvesters give 10-100 microwatts from machinery.

The frontend IC matters. We use the BQ25570 — it does maximum power point tracking with cold-start from 100mV. Pair it with a supercapacitor for storage.

Our rule of thumb: if harvested power averages 3x your system consumption, you can run forever on a supercap. 1-3x, add a small rechargeable LiPo. Below 1x, harvesting extends life but won't replace the primary cell.

Key Takeaways

• Audit total system sleep current — the MCU is often the smallest contributor
• The voltage regulator is the highest-leverage component choice. A 60nA Iq part changes everything.
• Design firmware as an explicit power state machine. Target 99.9% time in deep sleep.
• Energy harvesting works when average harvest exceeds 3x average consumption.