Impedance-Track Fuel Gauge

This page explains why Impedance-Track (IT) must be written as an independent topic under the “Battery Charging / Gauging / Protection / BMS” system: it sits above simple Coulomb counting and OCV-only gauging, and it requires real in-field operating patterns — not just V/I snapshots.

In other words: “IT = learn while running.” If the system never gives it usable charge/discharge/rest windows, it will silently degrade toward a smarter Coulomb counter.

1. Why we need a dedicated IT Gauge page

We separate it from generic fuel-gauge content because IT devices consume operating patterns. They want to see how the pack is actually charged, discharged, stored and heated, so the internal model can be updated on-the-fly. That requirement does not exist for simpler gauges.

Important: this chapter does not describe the charger’s CC/CV state machine, does not define pack eFuse behavior, and does not re-draw multi-series AFE chains — those stay in their own subpages.

2. Impedance-Track core mechanism (compared with basic gauges)

An IT gauge can be viewed as three stacked layers: (1) a richer sampling layer (V / I / T), (2) a factory or chemistry-based base cell model, and (3) an on-the-fly correction loop that writes new parameters back only when the operating window is stable.

2.1 Sampling layer — what data it actually needs

IT devices are more picky than classic fuel gauges. They want bidirectional, temperature-aware current, pack or per-cell voltage that can settle during rest, and at least one temperature channel. Any compromise here will slow down learning.

• Current: high-resolution, sign-aware, ideally compensated for shunt temperature.
• Voltage: pack-level at minimum; cell-level if working with multi-series AFEs.
• Temperature: cell or board; two channels are better for distinguishing pack heating from board heating.

2.2 Base cell model — the starting point is never blank

Every IT implementation starts from a pre-assumed battery world: an OCV curve, an expected impedance profile, and capacity at a reference condition. Different chemistries or vendor packs require different tables. If the project later swaps to another battery family, the IT gauge must re-learn — it will, but it needs proper windows.

This is why, in cross-brand or cross-batch procurement scenarios, we do not treat IT gauges as “just another fuel-gauge IC”. The model is part of the value.

2.3 On-the-fly correction — when stable, update

The main loop is: measure → compare to model → back-calculate actual cell status → write back. The gauge only does this when it detects a trustworthy window (a clean charge/discharge or a proper rest). No stable window → no update → you slowly degrade toward a semi-smart Coulomb counter.

Typical write-back targets include: Qmax (usable capacity), cell or pack impedance terms, and sometimes temperature-related correction coefficients. Those are the values the MCU/BMS host should read and log — not just SOC%.

2.4 Why impedance is the decisive extra dimension

Aging shows up in impedance first, not in OCV. Light-duty or shallow-cycling applications do not give enough OCV movement to reveal aging. Packs from different vendors may share similar OCV curves but show very different internal resistance. IT uses that resistance change to adjust SOC/SOH so the display stays believable.

2.5 MCU / BMS host responsibilities

The host must read updated IT parameters, not only SOC; tag data sets that came from maintenance or test profiles so the gauge can treat them as high-quality; and help re-train when procurement swapped the gauge IC to a look-alike part. Otherwise the system will look like it is running IT while in fact it is running a “pseudo-IT”.

3. Learning Cycle design for Impedance-Track gauges

For an Impedance-Track (IT) fuel gauge, the so-called “learning cycle” is not an optional optimization — it is the prerequisite for the gauge to start tracking the pack’s real behavior. If the system never produces a charge → discharge → rest chain that the gauge considers stable, IT can only extrapolate and your SOC/SOH will slowly degrade toward “mostly guessed”.

This chapter separates naturally occurring user cycles (often incomplete) from engineer-enforced cycles (maintenance, production, test-mode), so you can plan where to insert a learning-friendly profile and tell purchasing “this part really needs that window”.

3.1 What is an “effective” learning cycle?

A cycle is considered effective only if the gauge can detect all three parts and treat them as reliable:

If any of the three is missing or noisy, the learning attempt will be postponed. You may still get SOC, but it comes from a model that did not truly adapt.

3.2 Why real projects rarely produce one

In the field, usage patterns are messy:

• Users charge only 20–40%: the gauge sees many little charges, no real “end of charge”.
• Automotive/embedded modules power up briefly: they work hard, then turn off — no time to rest.
• Servers / storage keep trickling: background float makes the “rest” look like “still charging a bit”.

None of those patterns are hostile to the charger, but they are hostile to IT learning.

3.3 Three engineer-made learning cycles

To make IT useful even in messy systems, engineers can manufacture a high-quality learning window:

3.4 Minimal interface with the Charging line

We do not redefine CC/CV, JEITA or USB-C behavior here. We only tell the charging side: “leave me a clean few-minute window with no trickle”. That alone will raise IT learning success a lot.

3.5 Deep point: one good cycle beats many noisy cycles

Once the gauge has seen one high-quality learning cycle, many later low-quality daily runs can still be ingested — the gauge already has a confident model to nudge. If you never give it that one good cycle, everything you see later is a best-effort estimate.

4. Rest and self-discharge detection

Many BMS teams think “we already have current sensing, so rest is obvious”. For IT gauges it is not. IT cares about a very quiet window in which current, voltage and time all meet strict limits so the internal model can trust the observation. If rest is noisy, the gauge simply logs rest not stable and does not update aging or impedance.

4.1 Rest conditions (I / V / Time)

• I ≈ 0: actually within a band, typically |I| < Ix. The Ix value depends on the product family.
• V stable: ΔV must stay inside a narrow window. If V keeps stepping, IT cannot tell load from leakage.
• Time satisfied: several minutes to tens of minutes. 1–2 seconds is not a rest for IT.

4.2 Why rest frequently fails

4.3 Self-discharge detection logic

During an accepted rest window the IT gauge watches the voltage decay slope and compares it to what the chemistry table says is acceptable. If the observed slope is worse, it classifies the event as self-discharge and updates the corresponding aging/leak terms in the model.

This is powerful — but only if the system is truly quiet. If the board is still leaking or the charger is still topping, the gauge may learn from system-side leakage instead of the cell. That’s why we clean the system before telling the gauge to measure.

4.4 What engineering can do

• Disable non-critical loads right before planned rest.
• Force the charger to off / hi-Z for a few minutes so the gauge sees a genuine no-current state.
• Set a “you may measure now” flag on brands that support host-assisted gauging.

4.5 Why logs show “rest not stable” so often

That line is not a fault. It is the gauge telling you: “I saw something that looked like a rest, but your system was still moving, so I refused to learn from it.” In practice, the fix is almost always on the system side — stop trickle, stop PWM, or schedule a proper maintenance rest.

5. Aging / SOH online model update

This is where Impedance-Track (IT) pulls away from ordinary fuel gauges. A classic gauge can estimate SOC, but an IT device can write back what it just learned — Qmax, impedance, temperature terms — right into its internal model. If procurement silently swaps to a part without this path, you effectively lose the most valuable capability.

5.1 What variables must be updated

Certain vendors also keep a dynamic SOH, i.e. a health number that moves with real usage, not a fixed 80%/70% threshold.

5.2 When IT decides to update

Online updates are not random. They are tied to recognizable, high-confidence operating windows:

5.3 Why it must stay online (not pre-burned)

Pre-burned tables only describe the battery family you thought you would use. Real-life deployments drift:

• Cell supply changed: next batch is from another plant or even another brand.
• User habit changed: went from full cycles to shallow daily charges.
• Temperature band widened: device sits in a car, warehouse, or outdoor cabinet.

IT’s online update is how you keep accuracy in those situations — not how you get initial accuracy.

5.4 Risks when swapping brands / parts

6. Minimal coordination with the charging path

IT is not trying to own the charger. It only needs the charger and the BMS host to give it recognizable charge phases, at least one real rest window, and a way to tag important events. If those are missing, IT can still count Coulombs — but it will look like a fancy Coulomb counter, not a self-updating gauge.

This chapter only describes the interface. It does not redefine JEITA, CC/CV, USB-C sink negotiation, or buck-boost charger behavior. Those stay in their own charging pages.

6.1 What IT needs from the charger (3 conditions)

6.2 What IT needs from the BMS host (2 conditions)

6.3 Why we call it “minimal coordination”

Because the charging line will later branch into USB-C sink + charging coordination, buck-boost battery chargers, multi-cell charger controllers, etc. Those pages will talk about topology and protection; this page only tells them what IT can actually consume.

6.4 What to re-validate when crossing vendors

• Rest current threshold differs: vendor A thinks <5 mA is rest; vendor B wants <1 mA.
• Trickle current differs: some chargers never really stop, so IT never sees rest.
• Therefore: always test “this charger + this IT” together to see if the rest window is actually detected.

7. Seven-brand mapping and model-level writing

This chapter does not fabricate part numbers. It only defines how to write the seven brands in an Impedance-Track (IT) gauging context, and where real, publicly documented PNs will sit when we render the final HTML list. TI is the native IT line; the other six brands are positioned as “measurement front-ends”, “MCU-hosted IT routines”, or “companion sensors”.

7.1 TI (primary IT family)

Use this wording to stay consistent:

“TI Impedance-Track fuel gauge family (bq27xxx / bq28xxx / bq34xxx / bq40xxx) supports on-the-fly aging, impedance and SOH updates when valid learning cycles are present.”

For automotive/industrial lines, also allow: bq40z50-R2, bq41z90, and Q1 / extended-temp variants — but always write: “cross-check AEC-Q100 grade, temperature range and package before purchasing.”

7.2 ST

ST is best written as a V/I/T provider that can be used in IT-like flows:

7.3 NXP and Renesas

7.4 onsemi and Microchip (small-batch friendly)

7.5 Melexis (companion sensors)

Melexis devices like MLX91230, MLX91231, MLX90342 can act as high-accuracy current/temperature companions for IT-based packs, especially in automotive where the gauge IC does not integrate a car-grade sensor.

8. Small-batch procurement and cross-brand substitution

For small-batch buyers, the right sequence is: lock the IT function → then pick the brand / package / temp range. Do not start from “what is in stock” and later ask “why IT is not updating aging”. This chapter gives a reusable wording you can paste into RFQs and BOMs.

8.1 Step 1 — lock the function

Confirm that this project really needs: IT, on-the-fly aging/SOH, rest & self-discharge detection. If yes, prefer the following real parts:

8.2 Step 2 — can we temporarily downgrade?

You can bring up the system with STC3100 or other V/I/T monitors, but write in BOM: “mass production to migrate to native IT gauge.”

8.3 Step 3 — three substitution levels

8.4 Step 4 — small-batch channel strategy

• Buy industrial-grade first to confirm IT windows and learning work.
• Then place the automotive / Q1 order.
• Prefer distributors that support cut-tape / partial reel for 10–50pcs runs.
• For NXP/Renesas MCU+AFE parts, make sure the toolchain + sample projects are available before committing.

8.5 BOM remark templates

9. Validation, test, and write-back to the engineering library

This section shows engineering how to prove that an Impedance-Track (IT) fuel gauge is still doing real on-the-fly updates after procurement substituted the IC. Every step below can be screen-captured or logged and then written back to your internal library so purchasing cannot claim “it is pin-compatible so it must work”.

9.1 Bring-up / start-up validation

9.2 Learning-cycle validation

After the controlled profile finishes, you must see the model actually change. Otherwise you only proved that the IC can count Coulombs, not that it can update Impedance-Track variables.

9.3 Thermal-band validation

Impedance-Track is sensitive to temperature. When you swap to a different brand or a different FW base, repeat the learning cycle in the temperatures you are going to sell into.

• High-temperature run: run the same profile at e.g. +60°C and confirm that the gauge wrote back temperature-related terms.
• Low-temperature run: run at e.g. 0°C / –10°C and confirm the rest window is still detected.
• Write results as: 25°C = OK, 60°C = OK(slow), –10°C = Not stable (charger micro-top-off).

9.4 MCU / BMS host integration checks

9.5 Write-back to engineering library

Turn the above results into structured knowledge so purchasing cannot say “it is compatible, ship it”.

FAQ – Impedance-Track Fuel Gauge in BMS

All questions below refer only to this page’s scope: IT-based fuel gauging, learning cycles, rest/self-discharge detection, and cross-brand substitutions. They do not cover charger algorithms, pack eFuse topics, or unrelated fuel gauges.