Chapters

10 Energy Measurement and Profiling

energy-power
aware
measurement

10.1 Start With the Trace, Not the Datasheet

Measure One Complete Wake-and-Sleep Cycle

Picture a battery sensor whose average current looks low while short radio bursts drain it early. One average can hide the states that decide real life.

Duty cycle means the share of time a device spends active instead of asleep. Firmware means the software stored on the device. Record its version because software controls when many states begin and end.

Capture one complete cycle, then add a failed connection and restart. Keep current over time, state labels, software version, event count, energy, instrument settings, and unexplained gaps.

This runway does not prove lifetime in every field condition. The deeper sections explain instruments, sample limits, state budgets, burst capture, mismatch diagnosis, fixes, and battery-model boundaries.

Datasheets tell you what a part can do under stated conditions; the current trace tells you what your assembled device actually did. Both matter, but only the trace can prove the budget.

This chapter follows the measurement loop: predict the state budget, capture it with the right instrument, explain mismatches, then keep the evidence with the design decision.

Battery Bruno, the power-budget guide

Battery Bruno

“A budget on a spreadsheet is a guess — the trace is the only thing that gets to call it a fact.”

Here Bruno picks the tool for the pulse he's chasing and reads a bad trace for what it's really telling him.

In 60 Seconds

Energy measurement turns a power budget into evidence. Measure the complete device current over time, isolate sleep and active states, correlate current pulses with firmware events, and use the measured duty cycle to update battery-life estimates.

The mathematical gist. At the chapter’s 200 mA pulse, a 1-ohm measurement shunt drops 0.200 V. A catalog-typical 10-ohm CR2032 internal resistance drops another 2.00 V, so a 3.0 V open-circuit cell reaches only 0.80 V at the load with the meter connected. Removing the shunt recovers 0.20 V, but the cell’s own 2.00 V sag still dominates.

Math Bridge · guided foundationsWhich voltage drop belongs to the meter, and which belongs to the cell?Let Battery Bruno separate shunt burden from battery sag before the pulse measurement is trusted.

10.2 Energy Measurement and Profiling

A low-power design is not finished when the spreadsheet looks good. It is finished when the hardware, firmware, sensors, radio, regulator, and debug path have been measured together under realistic operating conditions.

This chapter focuses on practical measurement: choosing the right instrument, sizing a shunt without disturbing the device, capturing a full current trace, explaining anomalies, and converting the trace into an average-current estimate that can be tested again after each fix.

10.3 Learning Objectives

By the end of this chapter, you will be able to:

  • Choose a measurement method for sleep current, active current, radio bursts, and startup transients.
  • Explain burden voltage, shunt power, dynamic range, and why one fixed shunt often cannot cover the whole profile.
  • Build a repeatable measurement setup that isolates the target device from USB, LEDs, debug adapters, and regulator leakage.
  • Capture a full duty-cycle trace and connect current spikes to firmware states.
  • Calculate average current from measured state charge and use it to update battery-life estimates.
  • Identify common measurement mistakes before they turn into false optimization work.
Minimum Viable Understanding
  • Measure the complete product rail, not only the MCU, when estimating deployed battery life.
  • Measure the isolated target rail, not the USB input of a development board, when validating sleep current.
  • A multimeter can check steady current, but it usually misses short radio, sensor, and wakeup pulses.
  • A shunt resistor creates voltage drop; too much drop changes the circuit you are trying to measure.
  • Battery-life estimates should come from measured charge per cycle, not from a single datasheet sleep-current number.
Chapter Roadmap
  1. First you define the measurement question and decide whether the target is sleep current, state cost, battery survival, or before/after improvement.
  2. Then you choose the measurement chain, including shunt value, burden voltage, dynamic range, and instrument bandwidth.
  3. Next you capture the full duty-cycle trace and mark firmware phases so each current region has a cause.
  4. Finally you turn charge per cycle into a battery-life estimate, then use the quizzes and shunt deep dives to check the setup itself.

Checkpoints recap the practical rule; “Deep dive” and collapsed warnings are optional on a first read.

10.4 Measurement Evidence Loop

Good energy profiling is an iterative loop. The first trace rarely confirms the original model; it usually reveals hidden loads, extra wake time, radio retries, or a board path that was not in the spreadsheet.

Use the figure at Figure 10.1 to test the chapter’s measurement evidence loop claim before applying it. The visible relationship between state budget and and duty cycle identifies what must remain true in the real system.

No-panel energy measurement workflow showing budget prediction, instrument setup, duty-cycle capture, anomaly explanation, fix, and revised estimate.
Figure 10.1: Energy measurement evidence loop from predicted budget through instrument setup, trace capture, anomaly explanation, and revised battery-life estimate.

Reading the chart at Figure 10.1 from state budget to and duty cycle shifts the review from a point that adds a distinct review condition to one that adds a distinct review condition. Set Up adds the final condition by adds a distinct review condition. This explains why no-panel energy measurement workflow showing budget prediction, instrument setup, duty-cycle capture, anomaly explanation, fix, and revised estimate. It also supplies the bridge from the diagram back to measurement evidence loop.

10.5 Predict

List each state, expected current, expected duration, and wake frequency before measuring. The prediction gives the trace something concrete to confirm or reject.

10.6 Capture

Record the whole product rail during sleep, wake, sensing, processing, radio work, and return to sleep. A partial trace hides duty-cycle mistakes.

10.7 Explain

Tie every visible current region to firmware, hardware, or radio behavior. Unexplained spikes are defects until proven otherwise.

10.8 Recalculate

Update the average current and battery-life estimate from measured charge per cycle, then repeat after each fix.

You now know:

Sleep validation, state-cost diagnosis, battery survival, and before-and-after fixes require different measurement points. Begin by naming the question, then follow the evidence loop in order: predict the states, capture a complete duty-cycle trace, explain every region, recalculate measured charge per cycle, and repeat after the fix. This keeps the lifetime estimate tied to observed behavior instead of one attractive current value.

10.9 What to Measure

The measurement target depends on the question you are answering.

Question
Best measurement
What it reveals
Common trap
Does sleep mode work?
Isolated target rail during a long sleep interval.
Regulator quiescent current, pull-ups, floating pins, standby sensors, and debug leakage.
Measuring the USB input of a development board and blaming the MCU.
Which state costs most?
Complete duty-cycle trace with enough sample rate to capture short pulses.
Wake time, sensor warm-up, processing, radio association, receive windows, retries, and shutdown.
Using a slow meter average and missing brief high-current events.
Will the battery survive?
Measured average current over many full cycles, repeated at relevant voltage and temperature.
Whether the design still works when the battery sags, ages, or gets cold.
Dividing nominal capacity by best-case current.
Did the fix help?
Before/after trace with the same firmware path, supply voltage, load, and reporting interval.
Whether a change reduced charge per useful event instead of only changing the trace shape.
Comparing traces captured under different conditions.

10.10 Current Measurement Chain

Most IoT current measurements place a known impedance in series with the device supply and measure the voltage across that impedance. The instrument may be a multimeter, oscilloscope, current-sense amplifier, auto-ranging power profiler, or source-measure unit.

At this point, current measurement chain needs an inspectable chain rather than another rule of thumb. The figure at Figure 10.2 supplies it by linking bench source to series shunt.

No-panel current measurement setup with supply, shunt resistor, differential sense leads, measurement instrument, device under test, and GPIO marker.
Figure 10.2: Current measurement chain showing supply, series shunt, sense leads, instrument, device under test, and optional firmware marker.

Treat bench source, series shunt, and Device in the diagram at Figure 10.2 as three separate gates. The first establishes the starting condition, the second adds a distinct review condition, and the third adds a distinct review condition. Their combined message is specific: No-panel current measurement setup with supply, shunt resistor, differential sense leads, measurement instrument, device under test, and GPIO marker. Use that message, with its limits, in the ensuing current measurement chain decision.

The basic relationship is:

I=VshuntRshuntI = \frac{V_{shunt}}{R_{shunt}}

The design constraint is burden voltage:

Vburden=Imax×RshuntV_{burden} = I_{max} \times R_{shunt}

If the burden voltage is too high, the device sees a lower supply voltage and may behave differently. For example, a 100 ohm shunt gives useful resolution at 10 uA, but it would drop 5 V at 50 mA. That does not measure the device; it prevents the device from operating normally.

The abstract shunt symbol becomes useful only when its physical resistance and terminals are understood. The photograph in Figure 10.3 anchors that component before the measurement chain trades sleep-current resolution against wake-current burden voltage.

A small shunt resistor
Figure 10.3: A shunt resistor like this is the known impedance this chain measures the voltage across – the 100 ohm example just above is sensitive enough to resolve a 10 uA sleep current but would burn 5 V of headroom at a 50 mA wake current, which is exactly the burden-voltage trade-off this section is describing. Photo: wdwd, CC BY-SA 4.0

Begin Figure 10.3 at the R0002 resistance code and then compare the two large copper current pads with the narrower centre section. Current crosses the low-value element between the pads, and the instrument infers current from its voltage drop. The photograph therefore closes the loop back to the equations: choose a value high enough to resolve the quiet state but low enough that the wake burst does not lose unacceptable rail voltage.

For a sensor that sleeps at 10 uA and wakes at 50 mA:

  • To produce at least 1 mV at 10 uA, the shunt must be at least 100 ohm.
  • To keep burden voltage below 100 mV at 50 mA, the shunt must be at most 2 ohm.
  • One fixed shunt cannot satisfy both constraints.

Use switchable shunts, an auto-ranging profiler, or separate steady-state and transient measurements.

Battery BrunoCheckpoint: Shunt Tradeoff

You now know:

  • The current comes from Ohm’s law: I = V_shunt / R_shunt.
  • One fixed shunt may not span 10 uA sleep and 50 mA wake current without changing the device under test.

10.11 Tool Selection

The photographs below make oscilloscope a physical comparison: look for changes in package, exposed interfaces, mounting, scale, and service access before treating the forms as interchangeable.

Real photograph of oscilloscope
This real example (Sine wave 10 kHz displayed on analog oscilloscope) shows a physical form of oscilloscope. Use the visible package, interfaces, scale, mounting, and surrounding context as evidence; a catalogue label alone does not establish deployment fit. Photo: Pittigrilli; CC BY-SA 4.0
Real photograph of oscilloscope
This real example (Triangular wave and square wave on oscilloscope screen) shows a physical form of oscilloscope. Use the visible package, interfaces, scale, mounting, and surrounding context as evidence; a catalogue label alone does not establish deployment fit. Photo: User:Xato; CC0
Real photograph of oscilloscope
This real example (Tektronix digitizing plug-in 7D20 for 7000 series analog oscilloscopes) shows a physical form of oscilloscope. Use the visible package, interfaces, scale, mounting, and surrounding context as evidence; a catalogue label alone does not establish deployment fit. Photo: Pittigrilli; CC BY-SA 4.0

Read across the forms as engineering evidence. They share a capability name, but packaging and installation change the electrical, mechanical, environmental, and maintenance constraints.

Tool choice is about current range, time resolution, burden voltage, and repeatability. Avoid choosing a tool only because it is convenient.

Tool
Use it for
Strength
Limit
Digital multimeter
Steady current checks, simple shunt voltage readings, and quick sanity tests.
Simple, available, and good for stable loads.
Too slow for short duty-cycle pulses and often adds noticeable burden in current mode.
Oscilloscope plus shunt
Wakeup pulses, sensor warm-up, radio bursts, and firmware timing markers.
Shows current versus time and can align with GPIO markers.
Needs careful grounding, differential probing, and shunt selection.
Current-sense amplifier
Low-side or high-side sensing when the shunt voltage is too small for direct measurement.
Improves small-signal measurement while keeping the shunt low.
Bandwidth, offset, gain error, and common-mode range must match the device.
Auto-ranging power profiler
Devices that jump from low sleep current to high active or radio current.
Captures a wide dynamic range with fewer manual range changes.
Range-switching behavior and supply-mode limits still need to be understood.
Source-measure unit
Precise characterization across voltage, temperature, and very low current.
High precision and programmable sweeps.
Often slower or more complex than needed for ordinary firmware profiling.

A multimeter can hide the very transients that dominate an IoT cycle. Figure 10.4 shows the controls and display needed to decide whether an oscilloscope-plus-shunt setup can resolve those events.

A bench oscilloscope with a grid display and front-panel controls
Figure 10.4: An oscilloscope like this is the “oscilloscope plus shunt” entry in the table above: it is the tool that actually shows current versus time, catching the short radio bursts and wakeup pulses a multimeter blinks straight past. Photo: BekundaOff, CC BY 4.0

On Figure 10.4, look first at the two traces on the gridded screen, then move to TIME/DIV and VOLTS/DIV. TIME/DIV sets the horizontal window in which a wake or radio pulse can be separated; VOLTS/DIV determines whether the shunt’s small differential signal is visible without clipping the peak. The distinct CH1 and CH2 inputs also allow a state marker to be aligned with the current trace, which is the evidence the later power-profile analysis needs.

Bruno’s Power Budget

  • Draw: a multimeter reads steady current fine but blinks right past a millisecond radio burst.
  • Sleep: an auto-ranging profiler is the one tool built to span sleep-to-radio dynamic range without a manual switch.
  • Life: pick the instrument for the pulse you need to catch, not the one already sitting on the bench.

10.12 Capturing a Power Profile

A useful current trace should show the entire cycle: sleep baseline, wake, sensor stabilization, data acquisition, processing, radio activity, shutdown, and return to sleep. The trace is only useful if every region can be explained.

The risk in capturing a power profile lies between CURRENT and 10 µA. The map at Figure 10.5 exposes that gap so the next design step can use a bounded conclusion rather than a slogan.

A seven-state measurement cycle precedes a charge comparison: radio transmit uses 240 mA-s and deep sleep 9 mA-s. The radio uses about 27 times as much charge; measure the full cycle.
Figure 10.5: Annotated current profile for an IoT node showing sleep baseline, wake, sensor stabilization, processing, radio transmission, and return-to-sleep tail.

The first concrete marker in Figure 10.5 is CURRENT: it exposes the energy consequence. 10 µA changes the question by adds a distinct review condition, and 1 mA completes it by adds a distinct review condition. The figure therefore demonstrates that no-panel current profile trace with labeled sleep, wake, sensor, processing, radio, shutdown, and return-to-sleep regions. That conclusion rejoins the chapter’s capturing a power profile thread.

Capture enough cycles One clean cycle can be misleading. Capture multiple cycles so background timers, retries, maintenance tasks, and sensor warm-up variation can appear.

Mark firmware phases Toggle a spare GPIO at state boundaries so the current trace can be aligned with code paths.

Preserve the supply condition Measure at the voltage the product will actually see, including the lowest expected battery voltage.

Record the context Save firmware build, reporting interval, radio configuration, sensor load, supply voltage, temperature, and instrument range settings with the trace.

10.13 Firmware Markers

The trace shows when current changed; the marker tells you which code path changed it.

GPIO markers help connect a waveform to a firmware state without guessing. The marker pin should be measured on a logic input or scope channel; it should not drive a load that changes the power profile.

// Pseudocode: use a spare pin only as a timing marker.
void sample_and_report(void) {
    profile_marker_high();   // wake and sensor phase starts
    power_sensor_on();
    wait_for_sensor_to_settle();
    read_sensor();
    profile_marker_low();    // sensor phase ends

    profile_marker_high();   // communication phase starts
    radio_send_packet();
    radio_shutdown();
    profile_marker_low();    // communication phase ends

    enter_sleep();
}

Use markers sparingly. Too many markers clutter the trace, and marker code must not keep clocks, debug modules, or peripherals awake longer than production firmware.

Battery BrunoCheckpoint: Trace Interpretation

You now know:

  • A useful trace includes sleep baseline, wake, sensor stabilization, data acquisition, processing, radio activity, shutdown, and return to sleep.
  • Multiple cycles plus GPIO markers reveal retries, maintenance tasks, timers, and code phases that one clean cycle can hide.

10.14 From Trace to Battery-Life Estimate

The most useful output of profiling is charge per useful cycle. For each region:

Qstate=Istate×tstateQ_{state} = I_{state} \times t_{state}

Then:

Iavg=QstateTcycleI_{avg} = \frac{\sum Q_{state}}{T_{cycle}}

For a 10-minute environmental monitor:

Region
Measured behavior
Charge contribution
Design note
Sleep
18 uA for 598.1 s
3.0 uAh
Mostly board leakage and retained wake source.
Wake and sensor
8 to 40 mA for 0.3 s total
1.4 uAh
Short enough that sleep and radio still dominate.
Process
25 mA for 0.1 s
0.7 uAh
Optimization matters only if it also shortens radio work.
Radio event
120 mA average for 1.4 s
46.7 uAh
Largest cost; investigate retries, association time, receive windows, and payload size.
Shutdown tail
15 mA for 0.1 s
0.4 uAh
Confirms peripherals actually return to sleep.

Total charge per cycle is about 52 uAh. Because the cycle is one sixth of an hour, the measured average current is about 312 uA. A 2400 mAh cell with 80% usable capacity would be estimated at roughly 256 days before adding battery derating, temperature effects, self-discharge, and reserve margin.

The point is not the exact number. The point is that the radio event dominates the measured charge, so the next engineering step should be radio timing and retry reduction, not micro-optimizing a short CPU calculation.

Battery BrunoCheckpoint: Lifetime Evidence

You now know:

  • Charge per useful cycle is the evidence that connects a current trace to a battery-life estimate.
  • In the 10-minute example, the radio event contributes 46.7 uAh out of about 52 uAh, so it dominates the average.
  • The rough 256-day estimate still needs battery derating, temperature effects, self-discharge, and reserve margin.

10.15 Common Findings and Fixes

Now the estimate has pointed at the dominant cost; next, decide whether the symptom comes from hardware, firmware, radio behavior, or the setup.

Trace symptom
Likely cause
How to check
Typical fix
Sleep current is far above budget
LED, USB bridge, regulator quiescent current, debug adapter, pull-up, or sensor standby path.
Remove or isolate loads one at a time while watching the sleep baseline.
Power the target rail directly, remove indicators, choose low-Iq regulators, and force GPIOs to known states.
Unexpected periodic pulses during sleep
Timer, watchdog, radio maintenance, sensor interrupt, or background firmware task.
Use GPIO markers and disable suspected wake sources one at a time.
Move the task to the intended wake window or disable unnecessary wake sources.
Active window is longer than expected
Sensor settling, blocking network join, slow storage write, retry loop, or debug logging.
Mark firmware phases and measure each phase separately.
Batch work, shorten timeouts, remove debug logging, or change the reporting policy.
Return-to-sleep tail decays slowly
Peripheral shutdown sequence, capacitor discharge, regulator mode change, or radio not fully off.
Zoom in on the shutdown region and compare firmware shutdown commands.
Use explicit shutdown, wait for completion, and verify the final low-current state.

Bruno’s Power Budget

  • Draw: sleep current far above budget usually traces to an LED, USB bridge, or regulator quiescent draw, not the MCU.
  • Sleep: an unexpected periodic pulse during sleep is a timer, watchdog, or background task -- found by disabling suspects one at a time.
  • Life: a slow return-to-sleep tail often means a shutdown sequence never actually finished.

10.16 Validation Conditions

A single room-temperature bench trace is useful, but it is not final validation. Repeat the measurement under the conditions that can change energy behavior.

  • Final hardware: development boards include loads that production hardware may not have, and production boards include leakage paths that prototypes may hide.
  • Battery voltage range: radio transmit current, regulator efficiency, brownout margin, and sensor behavior can change as voltage falls.
  • Temperature range: leakage, battery capacity, sensor settling, and oscillator behavior can shift at temperature extremes.
  • Real radio conditions: weak signal, interference, acknowledgments, retries, receive windows, and connection setup can dominate the energy budget.
  • Real sensor load: wet probes, long cables, external pull-ups, and slow stabilization can extend active time.
  • Multiple units: one good board does not prove a manufacturing population.
Measurement Is Part of the Design

Do not treat profiling as a final demo. Profile early enough that the design can still change: regulator choice, antenna placement, sensor power gating, firmware wake policy, and reporting interval all become expensive to change late.

10.17 Knowledge Check

10.18 Knowledge Check: Measurement Point

10.19 Knowledge Check: Shunt Burden

10.20 Matching Quiz: Measurement Method to Use Case

10.21 Ordering Quiz: Repeatable Profiling Workflow

10.22 Label the Measurement Setup

10.23 One Shunt Cannot See Both Sleep And Transmit

Measuring a device's current usually means putting a small resistor - a shunt - in series and reading the voltage across it, since V = I x R. That voltage is called the burden voltage, and it is subtracted from the supply the device actually receives. The whole craft of current measurement is choosing a shunt that produces a readable voltage without stealing so much that it disturbs the device.

The hard part is dynamic range. An IoT node might sleep at 10 uA and transmit at 200 mA, a ratio of 20000 to 1. A single fixed shunt cannot serve both ends: a value large enough to make 10 uA readable would drop a device-killing voltage at 200 mA, while a value small enough to be harmless at 200 mA would produce an unreadable signal at 10 uA. That tension is why serious current measurement uses auto-ranging instruments.

Before wiring the measurement chain, inspect Figure 10.6. It makes the series-current path and the burden-voltage trade-off explicit.

Series shunt current measurement circuit showing a power supply, shunt resistor, device under test, measured shunt voltage, Ohm’s-law current calculation, and dynamic-range challenge.
Figure 10.6: The shunt must sit in series with the measured rail, and its value must be chosen so the voltage drop is both measurable and small enough not to change device behavior.

Read Figure 10.6 from the supply through the shunt to the device under test, then follow the sense leads to the measured voltage and current calculation. Finally compare the sleep-current resolution requirement with the peak-current voltage drop; that last comparison decides whether one range is defensible or an auto-ranging instrument is required.

Use the circuit as a setup checklist before trusting a trace. The supply, shunt, sense leads, and device must form one intentional measurement loop; measuring the wrong side of a regulator, USB bridge, or debug adapter changes the question. Record the shunt value and the maximum observed shunt voltage with every capture. For example, a 0.25 ohm shunt at 200 mA drops 50 mV, which may be acceptable; a 10 ohm shunt at the same peak drops 2 V and turns the measurement into a brownout test.

Intuition only: the shunt must be small enough not to disturb the peak current and large enough to resolve the sleep current. Those two demands usually cannot be met by one resistor, so the range must switch.

10.24 The Measurement Chain

Shunt resistor

Converts current to a voltage by Ohm's law. Its value trades resolution against burden.

Burden voltage

The drop the shunt steals from the supply. Too large and it changes the device's behavior.

Dynamic range

The sleep-to-peak current ratio, often tens of thousands to one, that one fixed shunt cannot span.

Bandwidth

How fast the chain can follow a transient. Too slow and it averages away the peaks.

10.25 Overview Knowledge Check

10.26 Size The Shunt For Burden Versus Resolution

Two inequalities bound the shunt. The burden limit keeps the peak drop small: R <= V_burden_max / I_peak. The resolution limit keeps the sleep signal readable above the amplifier's noise and offset: R >= V_min / I_sleep. When these two bounds cross, no single value works.

10.27 Worked Example: A Node From 10 uA To 200 mA

Target a burden under 50 mV at the 200 mA peak and a readable 100 uV minimum at the 10 uA sleep.

  • Burden limit: R <= 0.050 V / 0.200 A = 0.25 ohm. The shunt must be no larger than a quarter ohm.
  • Resolution limit: R >= 100 uV / 10 uA = 10 ohm. The shunt must be at least ten ohms.
  • Conflict: 10 ohm and 0.25 ohm are 40x apart, so one fixed shunt is impossible. Confirm the extremes: a 10 ohm shunt drops 0.2 A x 10 = 2 V at peak (brownout), while a 0.1 ohm shunt gives 10 uA x 0.1 = 1 uV at sleep (lost in noise).

The resolution is why auto-ranging exists: an instrument switches to a high-value shunt during sleep and a low-value shunt during the burst, satisfying both bounds by never using one value for both.

Write the rejected values into the measurement notes, not just the value you finally used. A 0.25 ohm shunt is acceptable for the 200 mA burst but gives only 10 uA x 0.25 ohm = 2.5 uV in sleep, so the trace may look flat even when the node is leaking. A 10 ohm shunt resolves sleep but drops 2 V in transmit, so any reset, retry, or missing radio packet could be caused by the measurement setup itself. That audit trail makes later battery-life evidence defensible.

10.28 Shunt Sizing Ledger

Constraint
Rule
Bound
Failure If Violated
Burden
R <= 50 mV / 200 mA
R <= 0.25 ohm
2 V drop at 10 ohm browns out the device
Resolution
R >= 100 uV / 10 uA
R >= 10 ohm
1 uV at 0.1 ohm is lost in noise
Both
Bounds cross
No single value
Requires auto-ranging or two shunts

10.29 Practitioner Knowledge Check

10.30 The Meter Changes What It Measures

Two subtle effects trip up current measurement. The first is perturbation through burden voltage. If the shunt drops a significant voltage during a current spike, the device's supply sags at exactly that moment. A sagging supply can change how much current the device draws - a regulator works harder, a radio adjusts its output, or the chip approaches brownout - so you end up measuring a different device than the one that runs without the meter. Keeping burden small, or using an instrument that regulates the voltage at the device despite the shunt, is what makes the measurement represent reality.

The second is bandwidth. Radio and processor currents change in microseconds, but an averaging multimeter reports a slow mean. A meter that shows 0.4 mA average tells you nothing about a 200 mA pulse hiding inside that average, and it is precisely that pulse that might brown out a coin cell. Capturing peaks needs a fast sample rate and enough amplifier bandwidth to follow the edges; an undersampled trace both misses the peak height and mis-estimates the charge in short bursts. This is why an average-only reading and a high-bandwidth capture answer different questions, and a full energy profile needs both.

A quick perturbation check makes the problem visible. If a temporary 1 ohm shunt sees a 200 mA radio pulse, the meter removes 0.200 A x 1 ohm = 200 mV from the device rail during exactly the highest-load event. On a partly discharged 3.0 V system that may be the difference between a clean packet and a brownout-driven retry. If the trace changes when you replace the 1 ohm shunt with 0.1 ohm, the first trace included an instrument-induced behavior.

Bandwidth creates the opposite failure: the circuit is not disturbed, but the evidence is blurred. A 120 mA transmit edge lasting 2 ms carries 120 mA x 0.002 s = 0.24 mA-s. Averaged over a 60 s reporting interval, that event is only 4 uA, so a slow logger can make the peak look harmless even though the source must deliver the full pulse instantly. Use fast traces for peak feasibility and integrated charge for lifetime estimates.

10.31 Errors That Look Like Data

Supply sag

A large burden drop during a spike lowers the device supply, changing the very current you are trying to read.

Averaging blindness

A slow meter reports the mean and hides the peak that actually threatens the source.

Undersampling

Too low a sample rate misses short bursts and mis-estimates their charge and peak height.

Range-switch glitch

Auto-ranging has a brief settling window during a range change; know where those blind spots fall.

10.32 Under-the-Hood Knowledge Check

10.33 Summary

Energy measurement keeps low-power design honest:

  1. Define the expected state budget before measuring.
  2. Measure the correct rail for the question being asked.
  3. Choose a tool that can capture both low sleep current and short high-current pulses.
  4. Keep shunt burden voltage low enough that the device still behaves normally.
  5. Explain every current region before trusting the battery-life estimate.
  6. Recalculate average current from measured charge per cycle and validate again after each change.

Common Pitfalls

USB input current, isolated MCU rail current, and final product rail current answer different questions. Record the measurement point with every trace.

Current ranges, shunts, long leads, and supply-mode limits can create voltage drop or instability. Check burden voltage during the highest-current event.

A single average-current number can hide a broken sleep state, repeated radio retries, or a long shutdown tail. Inspect the time trace before accepting the estimate.

Real deployments include weak signal, cold batteries, sensor variation, retries, and maintenance tasks. Capture representative conditions, not only the cleanest bench cycle.

10.34 What’s Next

10.35 Apply the Fixes

Low-Power Design Strategies explains how to reduce wake frequency, sleep current, active time, and peripheral leakage after profiling reveals the main drain.

10.36 Analyze State Budgets

Power Consumption Analysis builds the state-by-state budget that your measured trace should confirm or correct.

10.37 Size Harvesting Systems

Energy Harvesting Design depends on measured load current before solar, vibration, thermal, or RF harvesting can be sized responsibly.

10.38 Practice the Workflow

Hands-On Lab: Power Monitoring provides a lab-style path for connecting measurement data to design decisions.

10.39 Key Takeaway

No energy claim is credible without measurement. Use current traces to capture sleep, wake, sensing, compute, radio, retries, and startup costs, then compare measured behavior with the budget.