← Back to: Battery Charging / Gauging / Protection / BMS
In this section, we will explore Coulomb Counting and OCV Fusion techniques used for precise SOC and SOH estimation in battery management systems. These methods help improve the accuracy and reliability of battery health monitoring, particularly in automotive and energy storage applications.
Coulomb Counting Overview
Coulomb Counting is one of the most widely used methods for estimating the State of Charge (SOC) of batteries. By integrating the current flowing in and out of the battery, Coulomb Counting tracks the energy that has been transferred to or from the battery. However, this method is susceptible to errors due to sensor drift, which may accumulate over time, making it less accurate for long-term use.
Advantages of Coulomb Counting: it can provide accurate real-time SOC estimates, especially when there are no large current fluctuations. It directly tracks the amount of charge in the battery, providing a near-precise measurement of SOC under normal operating conditions.
Disadvantages: over time, accuracy can degrade because of current-measuring errors. Small drifts add up and the SOC gets offset from the real value. Periodic correction or fusion is required for long missions.
OCV Fusion Overview
OCV Fusion improves SOC accuracy by combining Coulomb Counting with open-circuit-voltage (OCV) measurements. Coulomb Counting is good for instant SOC tracking, but its error drifts. OCV gives an absolute reference when the battery is at rest.
How it works: when the battery has low or zero current, the system samples OCV, maps it to an SOC curve, and then corrects the Coulomb-based SOC. This keeps the SOC estimate anchored over long periods.
Benefits: long-term stability, less drift, better behavior for storage/idle phases, and more reliable SOH pipelines.
SOC and SOH Relationship
SOC is a dynamic level indicator; SOH is a long-term aging indicator. A BMS that fuses Coulomb and OCV for SOC will feed a more stable signal to the SOH estimator, which in turn enables smarter derating, range prediction, and service scheduling.
Temperature Compensation for Accurate Battery Health Estimation
Temperature is one of the strongest disturbance factors in battery estimation. Even if Coulomb Counting and OCV Fusion are correct, a non-compensated temperature can push SOC away from reality, and can make SOH look worse than it is. This chapter explains why temperature shifts voltage and internal resistance, and how a BMS should re-scale or re-fit SOC/SOH curves at runtime to keep accuracy across cold-start, nominal, and high-ambient conditions.
1) How temperature distorts SOC estimation
Battery voltage is temperature-dependent. At low temperature the open-circuit voltage can look lower for the same real SOC, and internal resistance (Rin) rises. If the BMS reads this raw voltage and maps it to a room-temperature OCV–SOC table, the SOC will be underestimated. At high temperature the opposite can happen: the same SOC may look like a higher voltage, so the system overestimates SOC. Both cases produce bad user experience (unexpected shutdown, wrong range prediction) and can mislead SOH learning.
A correct temperature-aware estimator should always ask two questions: (a) at what temperature was this OCV lookup built? and (b) what is the current cell/pack temperature? Once the delta is known, the estimator can shift the curve or apply a correction factor before updating SOC/SOH.
2) Temperature-compensation algorithms
A practical BMS rarely uses a single formula. Most automotive / ESS-oriented designs use tiered compensation:
- Table-based OCV correction: different OCV–SOC tables per temperature band (e.g. <0°C, 0–10°C, 10–35°C, >35°C).
- Rin scaling: internal resistance rises at low temperature; the algorithm multiplies the nominal Rin by a temperature factor before SOH learning.
- Blend with Coulomb data: when the pack is resting and current is small, OCV gets higher weight; when the pack is active, Coulomb Counting gets higher weight.
For a WordPress-based technical page, you should make this logic explicit with short paragraphs, because engineers will search for “battery temperature compensation SOC” and expect to find which variable to correct first: voltage → resistance → SOC → SOH.
3) High-temp vs low-temp strategies
Low temperature (sub-zero / winter cranking): voltage looks lower, Rin looks higher. The estimator should not immediately mark the cell as aged. Instead, it should tag the record with the actual temperature and delay SOH learning until the cell returns to the nominal band.
High temperature (packed ESS, under-hood): voltage droop is smaller, so SOC may be slightly overestimated. Here the risk is thermal derating: the BMS should combine temperature compensation with charge-/discharge-current derating so that SOH is not falsely improved.
In both cases, the BMS must time-stamp SOC/SOH samples with temperature. Without temperature context, historical SOH data becomes noisy and can mislead predictive maintenance.
Real-Time Rin Estimation and Its Impact on SOH
Internal resistance (Rin) is one of the most sensitive indicators of battery aging. A good BMS does not wait for capacity tests; it infers SOH from Rin trends collected during normal operation. This section explains how to calculate Rin from voltage/current events, how to reject bad samples, and how to feed the results into a long-term SOH learner.
1) What is Rin and why it matters
Rin (sometimes called DC internal resistance or dynamic resistance under a given pulse) describes how much the battery voltage drops when a certain current is drawn. As batteries age, active material degrades and the current paths get worse, so Rin increases. Even if the nominal capacity still looks acceptable, a high Rin means the pack will sag earlier, trip protections earlier, and run hotter.
Therefore, any SOH model that ignores Rin will report a “healthy” pack that in practice browns out under load. That is why modern multi-cell controllers and gauge ICs expose Rin-like metrics (impedance, ESR, or pulse resistance) so that the host MCU can map them to health bands.
2) Real-time Rin estimation from V–I events
The simplest way to estimate Rin in real time is to observe a short current step and measure the associated voltage step:
Rin = ΔV / ΔI.
In practice, we must:
- Choose events where ΔI is large enough (e.g. load turns on) so the measurement is above ADC noise.
- Sample very close to the step to avoid the slow electrochemical relaxation that would distort ΔV.
- Tag the temperature so we can normalize Rin later (link back to Chapter 3).
Some controllers do this automatically and export a filtered “battery impedance” register. If your IC does not, a WordPress-hosted technical article like this can still show engineers how to do it in firmware.
3) Linking Rin growth to SOH degradation
Once we have a stream of Rin values (each tagged with time and temperature), we can feed it into a slow SOH learner. A common approach is:
- Discard samples taken outside the nominal temperature band.
- Average Rin over several valid events to reduce noise.
- Compare the averaged value against the initial (commissioning) Rin.
- Map the percentage increase to SOH loss (e.g. +40% Rin → SOH 80%).
This is not a single correct formula – different chemistries age differently – but the trend is universal: Rin up → SOH down. Your article should make this explicit so purchasing / maintenance people reading it know why the BMS asks for “Rin-qualified cells” or why the design reserves ADC resolution for small ΔV.
The Impact of OCV Fusion on SOH Estimation
OCV Fusion is the missing piece that links electrochemical state (OCV) with operational state (Coulomb SOC) and aging state (Rin). Without OCV, SOH can be biased by temperature or by short-term load patterns; without Rin, SOH ignores the “can it still deliver current?” question. This section shows how to merge these signals in a temperature-aware way.
1) OCV Fusion working principle
When the battery is in a rest or low-current window, the BMS can read a relatively clean open-circuit voltage (OCV). This OCV is mapped to an OCV–SOC curve that was built at a known temperature. If today’s SOC from Coulomb Counting drifts away from that OCV-based SOC, the BMS can re-anchor the charge estimate. Once SOC is trustworthy, it becomes safe to push aging logic (SOH learning).
At the same time, the BMS receives periodic Rin / impedance values from load events. These values tell us whether the cell/pack is getting “harder to drive”. OCV gives where the chemistry stands; Rin gives how it behaves under stress. Fusing both gives a more stable SOH than “Coulomb-only” or “Rin-only” approaches.
2) Dynamic SOH evaluation from fused data
SOH is not a one-off number. In real fleets, the BMS learns SOH over time: whenever it detects a good OCV point (rested, temperature valid) it raises the confidence; when it only has Rin-based samples it updates the “can-deliver-current” part of SOH but keeps capacity unchanged. This is how we avoid false aging alarms on cold mornings or during brief high-power events.
A good fusion stack therefore stores: value, timestamp, temperature, operating mode (EV / ESS / UPS), and source (OCV / Coulomb / Rin). Later SOH is the weighted outcome. This article can show engineers what metadata to log even if their gauge IC does not implement full fusion in silicon.
Practical Applications and Use Cases
Coulomb Counting + OCV Fusion + real-time Rin is not academic – it solves very different problems in EVs, in stationary energy storage, and in telecom / UPS backup systems. Below we map the fusion logic to each scenario and show what the BMS should actually log.
1) Electric vehicle (EV / HEV / PHEV)
EV batteries hardly rest. That means clean OCV points are rare, so the BMS must rely on continuous Coulomb SOC and inject OCV corrections only when the car is parked, charging, or coasting at very low current. At the same time, traction loads give us a lot of chances to capture Rin events. This is why EVs are good candidates for a Rin-weighted SOH.
Another EV-specific benefit: once SOC and SOH are fused, range estimation can be temperature-aware – in winter, the BMS can de-rate remaining range because Rin is up and the SOC table was shifted.
2) Energy storage systems (ESS / racks / containers)
ESS has the opposite pattern of EV: lots of rest windows, but notable temperature gradients and multi-string layouts. That means we can do high-confidence OCV Fusion more often, but we must store temperature together with every SOH point. Also, when modules are paralleled, Coulomb data may not reflect the true per-string energy usage, so OCV becomes the primary reference for SOH.
A good ESS BMS will run the fusion per module, not per whole cabinet, and then feed the aggregated SOH back to the power controller to decide derating or rebalancing.
3) Telecom, UPS, and smart-grid backup
Backup batteries stay charged most of the time, so Coulomb tells us almost nothing. Here, OCV Fusion plus a few controlled discharge / load tests can converge SOH much faster than “capacity test once a year”. Rin is especially valuable because these systems care about “can it take the load right now?” more than “how many kWh are left?”.
Small-Batch Procurement and Cross-Brand Alternatives
This chapter turns the previous algorithmic work (Coulomb Counting + OCV Fusion + temperature + Rin) into real parts you can buy. The focus is on low-volume / fast validation / urgent BMS samples, where lead time, package, and availability are more important than keeping a single-vendor stack. We still limit ourselves to the 7 brands you specified: TI, ST, NXP, Renesas, onsemi, Microchip, Melexis.
1) Procurement scenarios to support Coulomb + OCV Fusion
Before picking ICs, classify the project. In small-batch BMS work we mostly see four patterns:
- A – Automotive/ESS demo: needs AEC-Q or at least industrial temp; will run fusion on the MCU; quantity 10–100 pcs.
- B – Lab validation board: wants voltage, current, temperature in one place to prove the fusion math; package can be generic.
- C – Multi-string pack: needs good voltage sampling from NXP/Renesas/TI AFE and will do fusion at host level.
- D – Export / client-choice: must quote “TI line”, “ST line”, “NXP line” for the same design so customer can select a brand.
Each of the 4 scenarios below will get a “primary” part and at least one “cross-brand” alternative to avoid redesign when something goes into allocation.
2) Brand-based IC pools (Coulomb / OCV / BMS front-end)
Below is a procurement-oriented breakdown. All of these parts can provide at least one of the signals needed by the fusion engine (V, I, T, or impedance-like data).
TI (Texas Instruments)
Primary fuel / gauge line, good for fusion hosts.
- bq34z100-G1 – multi-cell fuel gauge with Impedance Track.
- bq40z50-R2 – pack gauge, can expose data to MCU.
- bq76952 / bq76942 – multi-cell monitor/AFE for fusion on MCU.
- INA228 / INA226 – precision current/power, good as extra Coulomb source.
STMicroelectronics
Voltage-learning style gauges, often better lead time.
- STC3115 – fuel gauge with OCV assist.
- L9963E – automotive multi-cell BMS front-end.
- L9961 – 12 V automotive battery monitor.
NXP
High-voltage pack monitor chain, good for multi-module fusion.
- MC33771C / MC33772B – cell monitoring, voltage/temperature for fusion.
- MM9Z1J638 – 12 V battery sensor.
Renesas
Often used when NXP/TI are in allocation.
- ISL94216 / ISL94208 – multi-cell battery management.
- RAJ240090 family – BMS SoC side.
onsemi
Good for cost-sensitive single-cell / pack monitors.
- LC709204F / LC709203F – single-cell fuel gauge, I²C.
- NCD… monitor family – add-on measurement.
Microchip
Great when you want “any-voltage measurement” and run fusion on MCU.
- PAC1934 / PAC1932 – multi-channel current/power monitor.
- MCP39F511A – energy measurement, can feed log.
- MCP391x – precision ADC front-end.
Melexis
Not an all-in-one gauge, but excellent for high-accuracy current and temperature inputs.
- MLX91208 / MLX91216 / MLX91217 – hall current sensing for Coulomb.
- MLX90632 / MLX90614 – temperature sensing to de-noise OCV-based SOH.
3) Cross-brand replacement logic
For small batches you don’t want to re-write firmware each time an IC goes out of stock. Keep the fusion on the host MCU and treat the ICs as data sources. Then you can swap between vendors as long as they deliver (V, I, T) in comparable ranges.
| Function need | Primary (TI) | Alt (ST) | Alt (NXP) | Alt (Renesas) | Low-vol (Microchip/onsemi/Melexis) |
|---|---|---|---|---|---|
| Fuel gauge (multi-cell) | bq34z100-G1 | STC3115 | (MC33771C + MCU) | ISL94216 | PAC1934 + MLX91216 |
| BMS AFE (6–14 cells) | bq76952 | L9963E | MC33772B | ISL94216 | MCP391x + MCU |
| High-accuracy current | INA228 | – | – | – | MLX91208 / MLX91216 |
| Single-cell / portable fusion | bq40z50-R2 (reduced) | STC3115 | – | – | onsemi LC709204F |
Note: when crossing TI ↔ ST ↔ NXP, put fusion in firmware and unify temperature scaling; do not attempt to reuse vendor-specific OCV tables across brands without re-fit.
4) Lead-time and BOM remark strategy
For low-volume and fast BMS projects, you should write BOMs so that a distributor can swap within your 7-brand bucket without breaking the fusion logic:
- Remark 1: “Fuel gauge must support OCV-based correction or expose rested voltage; Coulomb-only gauges are not acceptable.”
- Remark 2: “Current sensor must support ΔI ≥ 1 A (or project value) step within t ≤ 5 ms so Rin events can be captured.”
- Remark 3: “Industrial temp (–40 to 85°C) acceptable for proto; target AEC-Q100 for SOP.”
This preserves the Coulomb+OCV+Rin path even when the exact TI or NXP part is temporarily out of stock.
Request a Quote
Frequently Asked Questions
This FAQ is scoped to the “Coulomb Counter + OCV Fusion + temperature + Rin” topic of this page. It does not cover generic EV diagnostics or unrelated battery chemistries. Answers are written for engineers who need to make the fusion run on real hardware.
How often do I need a real OCV rest to keep fusion accurate?
At least once per few days for automotive-like usage, and once per cycle for ESS. Rest means: current near zero, temperature stable, and cell voltages settled. If rest is rare, lower OCV weight and rely more on Coulomb + Rin.
What if my pack almost never rests (AGV / robot / taxi)?
Raise the Coulomb confidence, keep collecting Rin from load steps, and schedule artificial rests (maintenance windows) to refresh SOC from OCV. Without any rest, drift will accumulate.
Can I mix a TI gauge with an NXP cell monitor?
Yes, if fusion runs in your MCU and you normalize temperature and voltage scales. Do not mix vendor OCV tables directly; read both, normalize, then fuse.
Why does SOC drift after 1–2 weeks even when the system is off?
Coulomb offset, quiescent current, and temperature changes all cause slow drift. Use the zero-drift calibration from earlier chapters and refresh SOC from OCV when a rest window appears.
How do I calibrate Melexis hall sensors for Coulomb Counting?
Do a 2-point current calibration (low and high), then temperature calibration, then feed the result to the Coulomb integrator. Otherwise the fusion engine will keep correcting small drifts.
What temperature range should disable OCV-based corrections?
Typically below 0°C and above 45–50°C you should reduce OCV weight or discard the point, because voltage is too temperature-dependent there.
Can fusion run entirely on my host MCU?
Yes. Most of this page is written for “AFE + MCU” architectures. As long as the MCU can log V/I/T and a few Rin events, you can implement fusion in firmware.
How to avoid cold-weather Rin from polluting SOH?
Store temperature with every Rin sample and only feed samples within your “nominal temp band” into the SOH learner. Others are kept for diagnostics only.
What if cells from different vendors have different OCV–SOC curves?
Do the fusion per module or per string, not at whole-pack level. Mixed OCV curves must not be averaged blindly.
How do I choose between TI impedance-track and ST voltage-learning gauges?
If your system rarely rests, choose TI or run your own fusion. If you have frequent rest windows (ESS, backup), ST parts are fine and often easier to buy.
What should I write in the BOM to stop purchasing from buying a slower sensor?
Add: “Current sensor must support dynamic events for Rin calculation; no low-bandwidth replacements.” and “Gauge must expose rested voltage or OCV-based correction.”
Can fusion still work if the pack is always on charger?
Yes, but you need scheduled small discharge tests to create artificial OCV-like points. Otherwise SOH will become flat and uninformative.
Can I do fusion with only V and T, no accurate I?
You can, but it will be slow and better for ESS/backup. Add a proper current source as soon as possible to enable Rin and fast SOC fixes.
How can I lab-test the fusion chain quickly?
Emulate temperature steps, inject controlled ΔI, let the pack rest, and replay the logs. You do not need to wait for weeks of field data to validate the math.
How to detect fake / remarked gauge ICs in small batches?
Read device ID, register map, and OCV table version. If anything is off, mark it as “no-OCV IC” and keep it away from the fusion main path.
