An IoT prototype runs reliably over USB but restarts during wireless transmission when powered by a small battery. Before requesting a larger custom lithium battery, capture what happens to the supply during the reset.
The problem may involve the cell, the power path, the regulator, or firmware behavior. Battery capacity alone cannot identify the cause.
1. Record the Reset Cause Before Changing Hardware
Read the microcontroller’s reset-cause information early in startup, before your initialization code clears it.
Distinguish between brownout, watchdog, software-triggered, and other reset events supported by your platform.
Also record the operation immediately preceding the failure:
- Radio initialization.
- Network connection.
- Data transmission.
- Sensor startup.
- Flash write.
- Activation of another load.
A repeatable sequence gives you a trigger condition for the next measurement.
2. Measure Battery Voltage and the MCU Rail
A battery-voltage reading taken once per second may miss a short supply dip.
Use suitable measurement equipment to observe both the battery assembly’s output and the regulated MCU rail around the failing event. Capture current as well if your equipment allows it.
Keep the test configuration consistent. Connecting USB for debugging may change the power path and make the problem disappear.
Record:
- Minimum voltage during the event.
- Peak current.
- Pulse duration.
- Repetition rate.
- Battery state of charge and temperature.
Stay within the battery’s specified operating limits throughout testing.
3. Separate Average Consumption From Peak Demand
Average current is useful for runtime estimation. It does not describe every demand placed on the supply.
Consider this simplified battery-side profile:
| Operating state | Current | Time per cycle |
|---|---|---|
| Active | 20mA | 1 second |
| Sleep | 0.02mA | 59 seconds |
The time-weighted average is:
I_avg = (20 × 1 + 0.02 × 59) / 60
I_avg ≈ 0.353mA
These illustrative values are not measurements from a particular device. A real device may have additional startup spikes, retries, and background activity.
The low average does not establish whether the battery can support the active load without excessive voltage sag.
4. Find Where the Voltage Margin Is Lost
Compare the measurements across the power path.
| Observation | Useful next check |
|---|---|
| Battery output drops during the load pulse | Cell capability, state of charge, temperature, and assembly resistance |
| Battery output stays stable but MCU rail drops | Regulator limits, transient response, layout, and local decoupling |
| Battery output abruptly disconnects | Protection behavior and possible overload or fault |
| Supply rails stay within specification | Firmware, watchdog handling, reset inputs, and other causes |
These observations guide the investigation; none is a diagnosis by itself.
A first-order relationship is:
voltage drop ≈ current × resistance
Resistance in the cell, protection circuit, wires, and connectors contributes to the drop. Actual behavior also depends on electrochemical and circuit dynamics.
5. Test Whether Firmware Changes the Load Event
Check whether several operations start simultaneously.
For example, sensor startup, radio activity, and a storage write may overlap. Temporarily separating them can help reveal whether their combined demand contributes to the reset.
Also inspect retry loops and connection failures. A device in poor network conditions may behave differently from one tested beside an access point.
Use these changes to understand the problem, then validate the intended production behavior.
6. Give the Battery Manufacturer Measured Requirements
A useful specification includes the load waveform, peak duration, repetition rate, continuous current, operating temperatures, and device shutdown threshold.
Include the protection configuration and finished size limits. Ask the supplier to evaluate the complete assembly against that operating profile.
After selecting a candidate, repeat testing across the intended state-of-charge and temperature range.
The goal is to connect each reset to evidence—and approve a battery and power path that support the device’s actual behavior.
Top comments (0)