One Bluetooth Low Energy product, running on a constrained system-on-chip and its radio stack, powered by a coin cell. Part of the work was adding an I2C humidity sensor to the existing device without spending the battery. On a device like this the hard parts are the power topology and keeping the link alive under the radio stack. A blocking wait or a back-powering path costs battery life or drops the connection, silently, and nothing in the logs explains why.
On a coin cell, the current you cannot see decides the battery life.
A coin-cell device spends almost its whole life asleep. It wakes briefly to take a reading or exchange a few packets over Bluetooth Low Energy, then sleeps again. Battery life is therefore governed less by what the device draws when busy than by what it draws when it is meant to be doing nothing. A sleep current that is slightly too high, multiplied by every hour of the device's life, can outweigh all the busy moments put together. The quantities involved are small enough that a bench multimeter cannot resolve them, which is why measuring them takes a precision power analyser.
The usual way to save power on a sensor is to gate it: switch off its supply when it is not needed. Electricity, though, follows every path available to it. An I2C bus uses pull-up resistors to hold its two lines high when nobody is driving them. If those pull-ups are connected to a supply that stays on, and the gated sensor is still connected to the bus, current flows from the pull-ups into the sensor's pins and through its internal protection structures. The sensor ends up partly powered through its data lines. Its supply is off and it keeps drawing current anyway. This is back-powering, and it makes a gate that looks correct on the schematic achieve nothing.
The radio adds a second constraint, shaped by time. A Bluetooth Low Energy connection is a schedule of brief exchanges at agreed moments. The radio stack has to be ready for each of them, and if it misses enough in a row the link is declared lost. Firmware that waits in a loop for a slow sensor to finish its measurement can hold the processor through one of those moments. Nothing crashes and nothing is logged. The connection simply drops.
Both failures are paths, one electrical and one in time, and neither is fixed by choosing a better part. There is no model in this system. It is circuit topology, scheduling and arithmetic.
- Connection event servedthe link is healthy
- Firmware starts a measurementthe sensor needs time to finish
- Firmware waits in placethe processor is held
- Next connection event arrivesthe radio stack cannot run
- Events missed in a rowthe peer stops hearing the device
- Link declared lostand nothing in the logs says why
Adding a humidity sensor to a coin-cell device sounds like an exercise in choosing a part. It turned on two paths that no choice of part touches. The first is electrical: a power-gated sensor that shares I2C pull-ups with an always-on bus is fed through those pull-ups, so it never actually turns off. The second is in time: a blocking wait for the measurement holds off the radio stack, and the link drops. A lower-power sensor fixes neither.
Low-power designs leak through paths that are not on the block diagram.
Low-power design is usually taught as part selection: pick the sensor with the lowest sleep current, the regulator with the lowest quiescent draw, and gate whatever you can. Those choices matter, and they are what a datasheet-driven review checks. The failures that actually drain coin cells tend to sit between the parts, in paths through shared pull-ups, protection diodes, floating inputs and peripherals that were never fully switched off.
Radio links fail in a similar, quieter way. Bluetooth Low Energy stacks need the processor at specific moments, and code that holds the processor too long in the wrong place makes the stack miss them. The resulting disconnects are intermittent, depend on load and timing, and rarely produce an error that points at the cause. Both kinds of failure are invisible to ordinary instruments and ordinary logs, which is why they survive into shipped products.
The reflex, and the fix.
Gate the sensor and cut the signal
It reads as the correct low-power move, and it is exactly what a design driven by datasheets produces.
The shared pull-ups back-power the gated sensor through the bus, so it keeps drawing current, and a blocking read starves the radio stack and drops the connection. The gate looks right on the schematic and does nothing.
Fix the topology
Pull-ups fed from the regulated rail, a non-blocking read so the radio stack is never starved, and a gating arrangement that genuinely isolates the sensor.
Negligible impact as a property of the circuit, which a line in a specification can never provide on its own.
Treat it as a topology problem, because both failures are paths and neither is a part.
Pull-ups from the regulated rail
Pull-ups on an always-on bus feed a gated sensor through its data lines. Moving them to the regulated rail is what makes the gate actually switch the sensor off.
A read that never blocks
Waiting in place for the measurement keeps the processor away from the radio stack, and the link drops. The read is restructured so the stack always gets its turn.
Coin-cell arithmetic as the design frame
A single sensor read costs roughly 0.04 microamp-hours against an 850 milliamp-hour coin cell. That concrete pair turns negligible impact from a reassurance into a sum anyone can check.
Measured with an instrument that can see it
A precision power analyser was used where a bench multimeter is blind, because the currents that decide this design sit below what ordinary instruments resolve.
What each choice cost, and what it bought.
AMoving the pull-ups to the regulated rail
The tempting fix for a sensor that draws too much is a lower-power sensor. That would have spent money and changed nothing, because the current was arriving through the bus. Feeding the pull-ups from the regulated rail means the bus lines lose their supply along with the sensor, so gating it actually isolates it. It cost a change at the board level, which is harder to make than a change in firmware, and it removed the drain at its source.
BRestructuring the read around the radio
A blocking read is the simplest code to write: start the measurement, wait, collect the result. On this device that wait starved the radio stack. Making the read non-blocking meant splitting it into a start and a later collection, with the stack free to run in between. The code is less linear and harder to follow. In exchange the link stays up under measurement load, and the failure it prevents is one that would never have left a trace in the logs.
CTurning negligible into arithmetic
Negligible impact is a phrase that tends to survive review because nobody can disprove it. Pinning it to figures, roughly 0.04 microamp-hours per read against an 850 milliamp-hour cell, made it something anyone could check and anyone could break. That exposed the claim to scrutiny it might not have survived. Once checked, it held, and it now holds as a sum and not as an assurance.
DMeasuring below what a multimeter sees
A bench multimeter is quick and already on the desk, and at these currents it reports nothing useful. A precision power analyser took more setup and a more careful method. It was the only way the back-powering current, or the effect of fixing it, could be seen at all. Without it the design would have rested on assumption.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
Presented as one engagement rather than as separate clients. The sensor and radio work described here belongs to a single programme.
A design that gates the sensor, cuts the signal and claims negligible impact, while the cell drains quietly through the pull-ups and the connection drops under load.
Delivered firmware for the product, with the back-powering and non-blocking-read analysis as the decisive detail, and coin-cell arithmetic that turned negligible impact from a promise into a guarantee about the topology.
What it owns, and what it hands to a person.
The guarantee covers the topology as built. A later board revision that moves the pull-ups back to the always-on rail brings the same failure back with no code change and no error, which is why the finding is written down as a topology rule and not as a fixed defect.
When a specification promises negligible impact, ask which circuit makes it true. A promise about a component is not a guarantee about a system, and the difference is usually a path nobody drew.
Battery life on a sleeping device is decided by what it draws while idle. Measure idle current with an instrument that can actually resolve it.
Switching off a peripheral's supply does not switch it off if its data lines are held high from a rail that stays on. Trace every path into the part.
A blocking wait in firmware can starve a radio stack and drop a link with no error. Structure slow operations so the stack always gets its turn.
Turn a claim like negligible impact into a sum with real figures. Arithmetic can be checked, and an adjective cannot.
A fix that lives in the board topology can be undone by a later revision with no code change. Write it down as a rule the next revision has to respect.