← Back to: Battery Charging / Gauging / Protection / BMS
Pack Pressure / Leak Detection — Intro & Applicability
This page describes low-voltage, pack-internal pressure / leak detection channels that feed charging decisions, not HV insulation monitors. Keep this sentence as-is to prevent mixing with the “Insulation / Leakage Monitor (HV)” page in the same BMS hub.
We put this sensing channel inside the Charging domain because most swelling, micro-leak, or vent events are discovered while the pack is being charged, just charged, or charged under high ambient temperature. Charging is the only function that can immediately remove the heat source by derating or stopping the current.
For this reason, the signal flow must be: Pack → Pressure / Gas AFE → Charging state machine (CC → CV → Stop) → Maintenance log. We are not sending this to a slow upstream/vehicle diagnostic path first.
Applicable pack constructions
Pressure / leak detection only makes sense when the pack’s mechanical and sealing assumptions are known in advance.
- Fully sealed packs (rigid enclosure, O-ring / gasket): pressure signal is cleanest.
- Semi-sealed packs with vent / breathable membrane: pressure must be interpreted together with the vent characteristic.
- Packs with a one-way relief valve: you must capture the level before venting, otherwise the AFE only sees “after-release calm”.
In short: pressure sensing without a mechanical/sealing assumption = pseudo data.
What we are really trying to achieve
The goal is not “to display a nice pressure number”. The goal is: detect abnormal pack pressure/leak → trigger charge derating or stop → record the event so that purchasing, QA, or service will know this pack has already stressed the enclosure.
Once the event is logged, later batches and cross-brand alternates cannot say “we didn’t know this pack ever leaked”. That’s the real maintenance value.
Key questions this chapter must answer
You should be able to answer these three after reading:
- Which packs actually benefit from pressure / leak detection, and which ones won’t give stable data?
- Why do we bind the alarm to the charging state machine instead of sending it to a higher-level controller only?
- Why do we insist on maintenance logging instead of just lighting an LED once?
Pressure / Gas Sensing Front-End Types
To make this channel usable for small-batch procurement and cross-brand sourcing, we normalize it into three front-end routes. Each route has clear limits, so purchasing cannot casually replace a differential sensor with a single-ended one without re-characterization.
Route 1 — Absolute pressure sensor + simple conditioning
Typical 0.5–4.5 V ratiometric industrial sensors, easy to feed into a window comparator or a multi-level AFE. Select the range (for example 0–100 kPa) and check the temperature coefficient. Response time is usually fast enough to drive charging derating directly.
Route 2 — Differential / cavity pressure sensor + AFE
Used when the pack has a venting path, relief valve, or an external pressure port. This route captures the pre-vent peak, which is exactly what we want to use for charging decisions. If the original design expects a differential input, do NOT replace it with a single-ended-to-GND device unless the calibration table is regenerated.
Route 3 — Gas / VOC switch or conductive probe + threshold compare
Lowest cost, most likely to be “we’ve got some stock in the warehouse”. Good for event detection (leak happened) but not good for continuous pack stress estimation. Must be paired with temperature or event-count correlation (later chapters) to reduce false positives.
Many single-cell or linear chargers do not have spare sensor inputs, which is why this page pushes for a separate pressure/gas AFE that generates a clean, multi-level alarm line back to the charging domain.
AFE & Thresholding for Pack Pressure / Leak Detection
This chapter explains why pack pressure / leak detection must use multi-level thresholds. Charging has three distinct actions: L1 = continue but derate, L2 = large derate, and L3 = stop charging + log. If the AFE exposes only a single threshold, the charging domain will lose the middle step and can no longer protect the pack gracefully.
We therefore map the sensing output into three alarm grades and keep them in the Charging branch of the BMS hub.
Three AFE granularities
To support small-batch procurement and cross-brand parts, define the AFE in one of these three granularities:
- Single-threshold comparator — simplest and most easily “swapped in” by purchasing; good for L3 (stop) only.
- Window / multi-level comparator — gives L1 / L2 / L3 directly and is the best match for charging-state control.
- MCU-readable sensor front-end (ADC + registers) — raw value is digitized; firmware must still map it back to L1 / L2 / L3 for charging to act.
Do not replace multi-level pressure AFEs with single-threshold devices, otherwise charging derating logic cannot be preserved.
Key engineering questions
You should answer these before freezing the schematic:
- kPa or %FS? If the same board must accept different sensor ranges or brands, prefer %FS.
- Temperature coupling? L1 can follow the pack NTC table; L2/L3 are usually fixed or only slightly compensated.
- Latched or auto-recover? L1 can auto-recover; L2/L3 should be cleared by firmware or maintenance, and must go into the log.
For packs with a one-way relief valve, the AFE must treat the pre-vent peak as the L2 (or even L3) trigger. Post-vent readings are no longer representative, so they must not be used to relax the alarm.
Multi-level comparators should be selected with a documented reference-voltage tolerance. Only then can you approve cross-brand alternatives without redoing the full charging-derating characterization.
Alarm Routing to the Charging State Machine
This section shows how the L1 / L2 / L3 alarms from the AFE are actually connected back into the charging domain. We stay inside the Charging branch; we do not control pack FETs or HV contactors here.
Typical integration paths:
- Direct to charger IC (PROCHOT / THERM / FAULT pin) → fastest, ideal for L1 & L2 derates.
- To host MCU → MCU updates charge-current registers → slightly slower but allows correlation with NTC.
- Interrupt + log only → next power-up or next charge cycle forbids fast charge until maintenance clears.
Charging decision strategies
Depending on pack size and enclosure risk, choose one of the following:
- Derate only while alarm is present — for noisy gas sensors.
- Stop charging for the current cycle — for tight enclosures.
- Lock charging until maintenance clears — for service-heavy products.
Key questions
Is the alarm level-based or pulsed? — level is better for direct charger control; pulses are good for logging.
Do we need to notify an upper system? — by default this page stays local; remote notification is optional.
Will repeated alarms be mistaken as sensor failure? — time-stamp L2/L3 so service can tell the difference.
This section still stays in the Charging branch — do not move these alarms directly to pack-FET / eFuse control here. L2/L3 must carry a timestamp, and charging derating/stopping must be written back to the maintenance record or BOM remark.
Temperature / NTC Correlation for Pressure-Based Charging Actions
This chapter closes the biggest practical gap: pressure without temperature = high false positive rate. In many projects the original design used a pressure AFE plus pack NTC for derating. Then purchasing swapped in a device without temperature capability “because of lead time” — the port overheated. That scenario must be explicitly blocked here.
We correlate pack pressure with pack NTC or the same JEITA curve used by the charger, so that only “pressure high + temperature high” becomes a hard action. Other combinations are logged or redirected to thermal pages.
Three joint decision patterns
- Pressure high + Temp high → real pack stress → derate / stop (this is the one we want to react to fast)
- Pressure high + Temp normal → log only / re-test (can be mechanical/installation noise or slow ventilation)
- Pressure normal + Temp high → go to your thermal / JEITA page (not a pressure problem)
BOM remark (English): This product’s pressure alarm must be evaluated together with the battery NTC table. Do not approve AFE or sensor replacements that lack temperature-compensation capability.
Key engineering questions
- Which temperature table? If your charger already runs JEITA, reuse it. If pack layout makes NTC hotter/colder than cells, define a dedicated pack NTC table.
- Should pressure be temperature compensated? Yes, especially for semi-sealed packs and gas-based probes.
- Outdoor / large ΔT devices? Take 2 samples (start-of-charge and mid-charge) or average across a window.
Gas / VOC switches are more temperature sensitive than pure pressure sensors. Therefore this chapter must be applied even more strictly to gas-based “leak” channels: no NTC = disable correlation = must not approve.
Temperature readings must also go into the maintenance log (next chapter), so that service and purchasing can compare “pressure @ temperature” across different lots and substitutes.
Maintenance Logging & Counters for Pressure Events
This is the “maintenance logging” part mentioned in the page subtitle. Once the pack reports L2/L3, we must not let later purchasing or service assume “the pack was fine”. Logs make the history visible.
Three layers of data
- Event Log: each L2 / L3 → timestamp, pressure level (kPa or %FS), temperature (from NTC).
- Counters: how many times this happened in the recent N charge cycles → detect fatigued / poorly sealed packs.
- Service / Replacement Flag: when counter exceeds threshold → write to non-volatile → wait for maintenance.
If the AFE has its own registers, store events there. If the AFE is purely analog, store events in the host MCU / charger-side FRAM / EEPROM. If the alternate AFE does not have logging, firmware must take over and the BOM must say so.
Key questions
What if the log is full or gets lost? → set an upper limit and raise a “maintenance required” alert.
Should we upload the log? → this page stays local; remote upload is optional.
How to protect later batches? → write the real pressure/temperature pair into the BOM remark so substitutes can be evaluated against actual pack stress, not only against the schematic.
Maintenance logging is also the pre-field for “charging port / channel health tracking” in the same hub. If you skip it here, you will not have historical data for future BMS analytics.
Small-Batch Procurement & Cross-Brand Alternatives
This chapter protects the charging branch from being broken by purchasing. The original design assumed NTC-driven hotspot derating, multi-level pressure alarms (L1/L2/L3), and maintenance logging. If any of these are removed during sourcing, the whole safety chain becomes “pressure → one-bit → nobody knows why charging stopped”.
We therefore define three explicit replacement paths and tell purchasing when they are NOT allowed.
1) A → A (same brand / same family)
Use this when the original AFE is available in multiple ranges, packages, or temperature grades inside the same vendor family.
- Allowed when: the alternate keeps multi-level thresholding and exposes the same L1/L2/L3 signals to the charger / MCU.
- Not allowed when: the alternate drops the NTC / temperature pin, or merges all thresholds into a single alarm. In that case, firmware must be updated in the same ECO, otherwise the design is not equivalent.
- Note: same-family parts must preserve the reference-voltage tolerance, so that the charging-derating calibration remains valid.
2) A → B (cross-brand alternative)
Use this when the original brand has long lead time and you want to source from another of the seven approved vendors. Cross-brand replacements must rebuild the L1/L2/L3 behavior in firmware if the hardware interface is different.
How to describe the seven vendors in a way that fits your later programmatic PN pages:
- TI: sensor signal conditioners, window comparators, and low-voltage AFEs used in BMS / charger loops.
- ST: automotive / industrial sensor interfaces; watch the temperature grade when replacing.
- NXP / Renesas: PMICs and MCU-integrated comparators — when replacing these, charging thresholds must be synchronized in firmware, because the decision logic lives in the MCU.
- onsemi / Microchip: low-power sensor front-ends, good for small batches and short lead times; if logging is missing, the host MCU must log instead.
- Melexis: if the original part was chosen for automotive, magnetic, or special enclosure sensing, do not downgrade to consumer-grade without requalification.
Not allowed when: the cross-brand part provides only a single fault pin while your schematic and charging state machine expect three distinct levels. In that case the BOM must say: “Charging derating logic must be re-implemented in firmware for this substitute.”
3) A → Simplified (single comparator / switch-only)
This is the “we only have a basic comparator in stock” path. It is acceptable only when the pressure/leak channel is used for logging-only or when the product has another, stronger thermal / gas safety path.
- Allowed when: the product can tolerate “1-bit = abnormal, check it later” behavior.
- Not allowed when: this page is already tied to the charging branch (which it is), and the charger needs to know whether to do L1 derate or L3 stop. In that case, the firmware must be changed in the same ECO.
- Hard rule: If procurement downgrades a multi-level AFE to a single comparator, charger firmware must be updated in the same ECO, otherwise the entire charging protection chain is broken.
BOM remark templates (English)
Use these three sentences repeatedly on small-batch builds so later buyers do not “simplify” the channel:
1. Pack pressure/leak detection channel is required to be temperature-compensated; do NOT replace with AFEs that lack NTC or multi-level threshold support.
2. Charging must derate or stop when Level-2/Level-3 pressure alarms are present. This behavior shall be preserved when sourcing cross-brand alternatives.
3. If the selected sensor/AFE does not support maintenance logging, host firmware MUST implement event counters before approving the part change.
Procurement-critical notes
Small-batch orders are the easiest places for people to “drop the logging” because they want to build fast. This page must therefore say:
- Maintenance logging must not be removed. If the AFE cannot log, the MCU must log.
- NTC / temperature correlation must not be removed (see Chapter 5).
- Multi-level thresholds must not be collapsed to a single bit without changing charging firmware.
- For seven-brand alternates, keep a unified field description (brand, function, temp-capable, levels, logging) so your site can turn these into programmatic PN pages.
Validation & Periodic Self-Test
This chapter explains how to prove that the pressure / leak detection channel is actually alive — not just “sensor soldered”. Validation must follow the same 3-level logic as the charging domain: L1 (warn / derate), L2 (heavy derate), L3 (stop + log).
Production / line validation
On the line, we cannot really “pressurize” the pack. We simulate the sensor output with a fixture (voltage or resistance). The goal is to see the entire path: fixture → AFE → charging logic → log.
- The fixture should output at least three levels that correspond to L1 / L2 / L3 (e.g. 0.5 V, 1.2 V, 2.0 V).
- Line test must verify at least L1 + L3. Testing L3 only is not acceptable because this page explicitly relies on “keep charging but slower” behavior.
- If the input is gas / switch-type, the test must also simulate open-circuit and short-circuit conditions.
Slow / blockage faults (vent path, duct, hose)
Some packs fail not because the AFE is dead, but because the air/vent path is blocked. This is a slow fault. To detect it, run a long-time curve with a known input; if the AFE never reaches L1/L2 while it should, write a “needs inspection” entry to the maintenance log.
This entry must be visible to purchasing/service, so the next batch will not assume the pack is OK and allow full-power charge.
Periodic self-test (runtime)
To ensure the channel stays alive in the field, run a short self-test:
- When: at power-on, at each charge-start, and every N hours of operation.
- What: inject a known value (or switch to a reference) and see if the AFE / MCU reports L1/L2/L3 as expected.
- Log it: self-test results must go to the same maintenance log as real events (see Chapter 6).
User-side self-test is allowed, but must have a rate limit so the user cannot interrupt active charging all the time.
Key questions to answer
- Can mass production test L3 only? → No. At least L1 + L3 must be exercised to prove derating works.
- Can the user device run self-test? → Yes, via firmware injection, preferably at charge-start.
- Do we need re-calibration for aging / deformation? → Yes, add a zero-point or scale re-check into the maintenance strategy and log it.
BOM / maintenance notes
Test values must also be written into the BOM remark so that later substitutes can be compared against real, tested levels (not just the schematic value). This is especially important when the inlet is a gas / switch sensor with wider tolerance.
If the sensor requires periodic zero calibration, store the calibration result in the maintenance log — it becomes input for the future “charging port / channel health tracking” pages in the same BMS hub.
Request a Quote
This page handles pack-internal, low-voltage pressure / leak detection channels that feed back into the charging state machine (CC → CV → stop). It does not cover HV insulation monitors, multi-cell balancing routines, or pack FET / eFuse level cutoffs. Actions described here must stay in the charging branch, and charging derate / stop must be preserved when sourcing alternatives.
Frequently Asked Questions
Why do we need a pack pressure/leak channel if we already monitor pack temperature?
Temperature tells you the pack is heating, but it does not tell you the enclosure is accumulating gas or is poorly vented. Most swelling or micro-leak events appear during or right after charging, so the safest place to react is the charging state machine. The pressure/leak channel gives a fast, enclosure-specific trigger, and the NTC gives the context. Use both together, and keep the charging derate / stop logic preserved in every alternative.
Can pressure alarms directly stop charging, or should they only trigger derating?
Use a three-level strategy: L1 = continue but derate, L2 = heavy derate or stop-this-cycle, L3 = stop and log. Direct stop is justified for tight or sealed packs, but for semi-vented designs it is better to derate first and confirm with temperature. Whichever strategy you pick, make it part of the charging branch and require that charging derate / stop is preserved when the AFE or brand is replaced in small batches.
How do I set multi-level thresholds when the pack has a venting valve?
For vented packs, the critical information is the pre-vent peak, not the pressure after venting. Calibrate L2/L3 around the level right before the valve opens, so the charger can derate or stop before gas is lost. Always log the event with temperature, because the waveform will be gone after the vent. This preserves the charging protection chain without pulling in HV or pack-FET logic.
What if the pressure reading drifts because the enclosure slowly deforms over time?
Slow mechanical drift is expected on some housings. Handle it by periodic re-baselining and storing the offset in the maintenance log together with temperature. If the drift consumes too much of the sensing range, tighten L1 but keep L2/L3 unchanged. Do not disable the pressure channel and do not drop charging derate / stop just because the reference moved; instead, make the drift visible to procurement/service.
Can I use one AFE channel for both pressure and gas (VOC) sensors?
It is possible to share the channel, but gas/VOC probes are usually more temperature sensitive than pressure sensors. That means the design must keep the NTC / temperature correlation path active, and the MCU may need to rebuild L1/L2/L3 in software. When sourcing a simpler AFE, do not drop the temperature input; otherwise false positives will rise and the charger will lose its graded derate / stop behavior.
How do I correlate pressure alerts with the battery NTC to avoid false positives?
Use a 2×2 decision: pressure high + temp high → real pack stress → derate or stop; pressure high + temp normal → log only / re-test; temp high + pressure normal → redirect to thermal / JEITA rules. This way mechanical or installation noise does not trip charging. The key is to keep the NTC populated — procurement must not remove the NTC channel or the whole correlation collapses.
Can I replace a multi-threshold AFE with a single comparator in small batches?
Only if the charging firmware is updated in the same ECO to emulate L1/L2/L3. A single comparator gives you only “abnormal”, but this page needs to say “warn → derate → stop”. If firmware is not touched, then the replacement is not equivalent and should not be approved. Also move the maintenance logging to the MCU side if the simpler AFE cannot store events.
How should maintenance counters be stored if the AFE itself has no logging registers?
Store them in the host MCU / charger side FRAM / EEPROM. Each L2/L3 event should log timestamp, pressure (or %FS), temperature, and event type. Add an upper limit and raise a “maintenance required” flag if the log is full. This way small-batch substitutes that lack built-in logging will still preserve the charging protection history and future purchasing can see actual pack stress.
What’s the minimum sampling/scan rate for pressure during fast charge?
Sample at least as fast as the charging state machine makes decisions — typically hundreds of milliseconds to about one second for pack-level charging. Slowing the scan rate because the AFE was replaced is not acceptable; you could miss a vent-on-charge event. For slower gas/duct faults you can add longer windows, but L2/L3 actions must still be logged immediately.
How do I test the pressure/leak path during production without real gas/pressure events?
Use a test fixture that outputs equivalent voltages or resistances for L1 and L3 (ideally L2 as well). The goal is to verify the full chain: fixture → AFE → charger action → log. Production must not test L3-only because this page explicitly needs the derate path. Store the test levels in the BOM so later cross-brand parts can be checked against the same thresholds.
Which vendors support automotive-grade sensor front-ends suitable for pack pressure monitoring?
The seven vendors in this hub are: TI (sensor signal conditioners / window comparators), ST (automotive/industrial sensor interfaces), NXP and Renesas (PMIC / MCU-integrated comparators), onsemi and Microchip (low-power sensor front-ends for small batches), and Melexis (for automotive or special enclosure sensing). When switching brands preserve the multi-level alarms and the temperature-compensated behavior so charging derate / stop still works.
How do I write a BOM remark so purchasing won’t pick a sensor/AFE without temperature compensation?
Use a hard remark such as: “Pack pressure/leak detection channel is required to be temperature-compensated; do NOT replace with AFEs that lack NTC or multi-level threshold support. Charging derate/stop must be preserved.” This makes it clear that simpler comparators are not drop-in parts and that, if logging is missing, the MCU must implement event counters before approving the change.
