Your Multimeter Cannot See Your Sleep Current

Mostafa Dhouib·10 min read

Your Multimeter Cannot See Your Sleep Current

The short answer. In a low-power connected device, current consumption spans several orders of magnitude across one duty cycle, from microamps while asleep to tens of milliamps while transmitting. A bench multimeter takes samples and integrates them over its own measurement window, then switches ranges when the signal moves, so it is effectively blind across most of that span. It will report a smooth, plausible number that corresponds to nothing the device actually did. A purpose-built power analyser resolves the whole range at once, which is what lets you measure the quantity that matters, which is charge per event rather than current. And the rule that saves the most time on any battery investigation is that if the meter says zero and the battery disagrees, the battery is right.

Someone shows me a power budget that says the device lasts for months, and a meter reading that supports it, and a product that flattens a cell in days. All three of those are consistent, once you know what the meter is doing.

What the meter is actually doing

A digital multimeter is not a current probe. It is a voltmeter across a shunt resistor, sampled by a converter, with an averaging stage and an autoranging front end. Each of those three parts breaks a duty-cycled measurement in its own way.

It integrates over an aperture. The meter accumulates for some interval and reports one number per interval. An event shorter than the aperture does not appear as an event. It appears as a small lift in the average for that interval, indistinguishable from the device having been slightly more awake throughout. The shape, the duration and the peak are all gone before the number reaches the display.

It autoranges, and ranging is blind. When the current moves from microamps to milliamps the meter has to change range, which means changing shunt. During the switch it is not measuring. So the instrument reliably stops looking at exactly the moment the interesting thing happens, and then resumes in time to show you the tail of it.

The shunt changes the circuit. This one is the most damaging and the least discussed. To resolve microamps the meter inserts a large shunt, because it needs a measurable voltage from a tiny current. That large shunt then develops a substantial voltage drop when the device wakes up and pulls tens of milliamps, which is called burden voltage. The supply at the device sags. Depending on how much headroom you had, the radio misbehaves, a brownout detector fires, or the device resets.

So a meter configured to see your sleep current prevents the device from behaving normally while awake, and a meter configured to survive the awake current cannot resolve the sleep current. There is no setting that does both, and that is a property of the architecture rather than a matter of buying a better handheld.

Why averaging defeats a duty-cycled measurement

A single average current is a lossy summary, and the loss is exactly the information you need.

Many different behaviours produce the same average. A device that wakes briefly and draws a lot, and a device that never properly sleeps and draws a little continuously, can report an identical figure. Those two devices need opposite fixes. One needs its event made cheaper and the other needs its idle state found and removed, and the averaged number cannot tell you which one you are holding.

An average is also only a valid predictor of battery life if it is taken over a whole number of complete cycles, with every state represented in its true proportion. A handheld display updates a few times a second, asynchronously to your duty cycle, so what you read is an arbitrary window. Watch it for a while and you will see it wander, and the wander is not noise in the device, it is the beat frequency between your duty cycle and the meter's aperture.

The practical symptom is a team that reports a different sleep current every time it is asked, concludes the device is unstable, and goes looking for a firmware bug that does not exist.

Measure charge per event, not current

The change that fixes the measurement is a change of unit.

Current is a rate, and the device does not have a rate, it has a sequence of events. So stop asking "what is the current" and start asking "how much charge does each thing cost". Charge, in microamp hours or millicoulombs, integrated over a defined window with a defined start and end.

Charge per wake. From the moment the processor comes out of sleep to the moment it returns, including the startup transient and the regulator settling.

Charge per sample. One sensor acquisition, including whatever has to be powered to perform it.

Charge per advertising event and per connection event. For a radio, these are the recurring costs and they are usually the dominant term.

Charge per actuation. For anything with a motor, including the inrush when its rail is enabled.

The sleep floor, as a current. The one quantity that genuinely is a rate, because it is continuous.

With those in hand, battery life is arithmetic. Capacity divided by the sleep floor plus the sum over event types of charge per event multiplied by events per hour. Every term is separately measurable, and that is the real prize, because when battery life regresses you can attribute the regression to one term rather than restarting the investigation.

A per-event decomposition also makes design trade-offs discussable. Halving the advertising rate has a predictable effect on a line item. Choosing a different part changes a different line item. Without the decomposition both arguments are speculation dressed up with a datasheet number.

What a power analyser gives you that the meter cannot

A purpose-built low-power analyser is not simply a more accurate meter. It differs in the properties that matter here.

Wide dynamic range without range-switch blanking. It resolves microamps and tens of milliamps in the same capture, so an event is visible against the floor it rose from, rather than appearing as a gap in the record.

Low and constant burden voltage. It regulates the supply to the device and measures the current it delivers, so the device sees a stable rail at all current levels. The measurement stops perturbing the thing being measured, which means what you record is what the device actually does.

Enough sample rate to see shape. You get the duration of the transmit burst, the settling time after wake, the inrush spike, and the long low tail nobody suspected. The shape is what tells you which part of the firmware to look at.

Integration over a chosen window. Select a region and get the charge directly, which is the unit you actually wanted.

Correlation with digital markers. Drive a spare pin high at the start of a code region and low at the end, capture it alongside the current, and the trace becomes labelled. This is the single highest-value habit in low-power work. It converts a current plot, which shows you that something expensive happened, into a profile, which shows you which function did it.

If you do not have one

The gap is not all or nothing, and there are useful intermediates.

A shunt and an oscilloscope. You lose the dynamic range and you have to pick a shunt that compromises, but you gain the time resolution, so you can at least see the shape and duration of an event. Pick the shunt for the active state and accept that you cannot see the floor.

Discharge a capacitor. Power the device from a known capacitance and measure how long the voltage takes to fall by a known amount. That integrates everything honestly over a long window, which is precisely what a handheld refuses to do. It is slow and it is coarse and it does not lie.

A coulomb counter in the design. Adding a charge-counting part to the board gives the device the ability to report its own consumption in the field, which is worth more than any bench measurement because it covers the real duty cycle rather than the one you simulated.

Markers on a pin, always. This costs one pin and a few lines of code and makes every subsequent measurement, with any instrument, interpretable.

The honest limit

A power analyser measures what the board draws on a bench. It does not tell you what a cell delivers in a product.

Cell behaviour under pulsed load depends on internal resistance, which rises as the cell ages and as it gets cold. A coin cell that comfortably supplies a transmit burst at room temperature on a fresh cell may sag below the brownout threshold on an old cell in winter, and no bench current measurement predicts that. You need to characterise against the actual cell, at the temperature range you claim, near end of life.

Self-discharge, leakage paths that only exist in the assembled product, moisture, flux residue and conformal coating all contribute terms that no analyser on a development board will show. And a measured duty cycle is a measurement of the duty cycle you chose to run, which is an assumption about user behaviour.

There is no model in any of this. It is a shunt, an integral and arithmetic, which is exactly why it is worth doing properly, because every term in it is checkable. The honest ceiling is that the numbers are a bound and a comparison tool, not a field battery-life claim. The only thing that produces a field battery-life claim is a fleet reporting its own charge consumption, and if that fleet disagrees with your bench, the fleet is right for the same reason the battery is.

FAQ

Why can a multimeter not measure sleep current correctly? Because consumption in a low-power device spans several orders of magnitude, from microamps asleep to tens of milliamps transmitting, and a multimeter integrates over its own window, blanks while it switches range, and inserts a shunt whose burden voltage sags the supply during the active burst. No single setting resolves the floor and survives the peak, so the reported figure corresponds to nothing the device did.

What is burden voltage and why does it matter here? It is the voltage dropped across the meter's own shunt. Resolving microamps needs a large shunt, and that same shunt drops a significant voltage once the device pulls tens of milliamps. The supply at the device sags, so the radio misbehaves or a brownout detector fires. The instrument changes the behaviour it is trying to record.

What should I measure instead of current? Charge per event. Charge per wake, per sample, per advertising event, per connection event, per actuation, plus the sleep floor as a continuous current. Battery life is then capacity divided by the floor plus the sum of each event's charge times its rate, with every term independently measurable and attributable when something regresses.

Why does my sleep current reading keep changing? Usually because the meter's measurement window is unsynchronised with the device's duty cycle, so each reading covers an arbitrary mixture of sleep and activity. The wander is a beat frequency between the instrument and the device, not instability in the firmware, and chasing it as a firmware bug wastes weeks.

What is the cheapest way to get a usable low-power measurement? Drive a spare pin high and low around each code region so the trace is labelled, then use a shunt and a scope to get the shape and duration of events, accepting that you cannot see the floor. For the floor, discharge a known capacitance and measure the voltage drop over a long window, which integrates everything honestly.

What does the rule about the battery mean in practice? If the instrument reports zero or near-zero and the battery still drains faster than your budget predicts, trust the battery. The battery integrates everything continuously with no aperture, no range switching and no burden voltage. A discrepancy between a meter and a cell is evidence about the meter, and treating it the other way round is how a continuous idle current survives a whole development cycle.