When does a second RC branch earn its place in a battery model?

Mohammad Rezwan Khan — Mon, 10 Aug 2026 20:17:25 +0000

Adding states to a model is easy. Showing that they explain repeatable behavior outside the calibration record is harder—and much more useful.

A one-RC equivalent-circuit battery model represents polarization with one dynamic voltage state. A two-RC model separates that response into fast and slow branches:

dV_fast/dt = -V_fast/(R_fast C_fast) + I/C_fast
dV_slow/dt = -V_slow/(R_slow C_slow) + I/C_slow
V_terminal = OCV(SOC) - I R0 - V_fast - V_slow

That extra branch is not automatically an improvement. It introduces another resistance, capacitance, and state, which can increase parameter correlation and make identification fragile. The second branch earns its place only when the data expose two distinct recovery scales and the fitted behavior survives a waveform that was not used for calibration.

A small held-out test

I maintain an open MATLAB example that fits positive two-RC parameters to a synthetic voltage record, then evaluates the fitted model on a separate pulse profile.

Quantity	Result
Calibration RMSE	0.401 mV
Held-out RMSE	0.440 mV
Estimated fast time constant	2.01 s
Estimated slow time constant	33.88 s

The close errors suggest that the two fitted recovery scales are not limited to the calibration waveform in this synthetic benchmark. They do not establish that the parameters describe a physical commercial cell.

Why the split matters

A low calibration error can hide several failure modes:

the optimizer may have learned one particular current waveform;
two parameter combinations may produce nearly identical calibration voltage;
the OCV-SOC curve may absorb error that belongs to polarization dynamics;
the pulse duration may be too short to identify the slow branch;
sensor noise or preprocessing may dominate millivolt-scale differences.

A held-out pulse does not solve every identification problem, but it asks a better question: does the fitted structure retain useful predictive behavior when the excitation changes?

Reproduce the check

The example is deliberately small and inspectable. From the repository root:

addpath('examples');
check_battery_2rc_fit

The runnable files, assumptions, and expected output are in the MATLAB two-RC model and identification example.

The implementation keeps resistance and capacitance positive, reports the two time constants explicitly, and separates calibration from validation output. A no-plot check makes the numerical behavior reproducible in a terminal or CI job.

What I would require for measured-cell use

Replacing the synthetic record is more than swapping a CSV file. A defensible measured workflow should document:

cell chemistry, capacity, temperature, age, and initial SOC;
current sign convention, sampling, synchronization, and sensor uncertainty;
an independently estimated OCV-SOC relationship;
separate calibration and held-out current profiles;
parameter sensitivity or confidence information;
residuals across SOC and temperature, not only one aggregate RMSE;
a same-data comparison against the simpler one-RC baseline.

The decision rule should be practical: retain the second branch only if its held-out residual improvement matters for the intended estimator, controller, or teaching objective and its parameters remain stable enough to interpret.

The useful question

For people who identify equivalent-circuit models from pulse tests: how do you choose pulse and rest durations that expose a slow branch without making the fit ill-conditioned?

Disclosure: I maintain the linked repository. This article was prepared with AI assistance and reviewed against the repository's documented equations, outputs, and limitations.

Hello DEV: Building Safer, Smarter Battery Systems

Mohammad Rezwan Khan — Mon, 10 Aug 2026 19:29:28 +0000

Hello DEV Community! 👋

I’m Mohammad Rezwan Khan, an Electrical R&D Engineer and PhD focused on battery thermal management systems (BTMS), lithium-ion battery safety and efficiency, and battery energy storage systems (BESS).

Why I joined

Engineering gets better when ideas move between disciplines. Battery challenges sit at the intersection of electrical engineering, thermal science, controls, data, and software. I joined DEV to share practical lessons from that intersection and learn from builders working across the stack.

What I care about

Safer lithium-ion systems
Smarter thermal management
Reliable, efficient energy storage
Clear engineering models and workflows
AI-assisted tools that help engineers reason and build faster

I’m especially interested in how simulation, data analysis, and automation can shorten the path from an engineering question to a trustworthy answer.

What I hope to share

I plan to write about battery-system engineering, BTMS, safety, BESS, modeling, and the tools that make technical R&D more effective. My goal is to keep posts practical, understandable, and useful to both specialists and curious developers.

Let’s connect

If you work on batteries, energy storage, embedded systems, modeling, AI-assisted engineering, or adjacent fields, say hello. I’d love to learn what you’re building.

What is one engineering challenge you’re excited to solve right now?

DEV Community: Mohammad Rezwan Khan