Why a harvesting charger inside a BMS-like charging branch

In this branch we are not charging the main traction / propulsion battery. We are powering self-sustained, low-power nodes such as sensor clusters, edge nodes, telematics boxes, tire / door / seat modules and gateway backups that must stay alive even when the vehicle or the main system is inactive. These nodes live on harvested energy and therefore belong to the charging domain of the BMS, but with a much smaller power scale.

Because PV, TEG and vibration sources are intermittent, low-voltage and high-impedance, the BMS layer cannot safely perform cross-brand substitutions unless the charger reports its state just like a normal BMS charger. That is why this page also enforces telemetry exposure, even though the power level is only in the mW to sub-W range.

Another reason to keep this page under BMS-防交叉v1 is purchasing: small-batch buyers often try to replace “any single-cell linear charger” for cost or lead time, but that breaks cold-start at ultra-low VIN and removes MPPT reporting. By putting this page inside the BMS charging branch, we can write BOM remarks that block such replacements.

What this page is (scope)

• Front-end for PV / TEG / vibration / piezo harvesting sources.
• Includes cold-start at ultra-low VIN (typically 80–200 mV for TEG, low-light PV).
• Feeds micro-power storage such as thin-film cells or supercapacitors.
• Exposes telemetry (source_v, MPPT state, storage_v) to edge / cloud for cross-brand mapping.
• Stays under the Charging domain of the BMS template.

What this page is not (anti-crossing)

• Not a 2S–6S multi-cell charger controller page.
• Not a Dedicated USB-C + Charging page.
• Not a High-power buck-boost battery charger page.
• Not a pack-FET / HV insulation / leakage monitor page.
• Not a “system-wide dual-supply / power-mux” design guide.

Keep a simple mental model: “multiple tiny sources → one harvesting charger → micro storage → cloud sees it → purchasing can swap inside 7 brands.”

BOM remarks to pre-fill:

• Do not approve harvesting chargers without a cold-start path for PV/TEG.
• Charger / gauge must expose charging state and MPPT zone to edge gateway.
• Cloud-side telemetry mapping must be updated before using cross-brand alternatives.

Source profiles: PV vs TEG vs Vibration (and why MPPT names are different)

Energy-harvesting chargers are only as good as the source profile they are tuned for. PV, TEG and vibration/piezo do not deliver energy in the same voltage, power or impedance window. That is why different semiconductor vendors expose different MPPT-related fields for what looks like “the same” harvesting charger. To support small-batch, cross-brand alternatives, the cloud side must normalize these fields.

PV (photovoltaic) profile

Typical indoor / low-light PV panels output between 0.3 and 2.5 V but the available power can change within seconds as the light source changes. PV sources are therefore a good match for fractional open-circuit voltage (VOC-ratio) MPPT. However, when the illumination is weak (early morning, indoor), the harvester must cold-start from this low voltage first; a plain single-cell linear charger cannot do that.

TEG (thermoelectric generator) profile

TEG sources often start as low as 80–200 mV, with a relatively high source impedance and a slowly changing temperature gradient. MPPT here looks less like “searching for a peak” and more like limiting input current / input power to prevent the harvester from collapsing the source. This is also the strongest argument to record cold-start VIN and time into the BOM so that purchasing does not replace the IC with a non-TEG-friendly part.

Vibration / Piezo profile

Vibration and piezo elements deliver rectified pulses at high impedance. Most designs first buffer this energy in a small capacitor and only then feed it to the harvester. In such cases, the “MPPT” side is effectively a windowed / buffered intake that tries to avoid overloading the source while still charging the storage device.

Because the three sources have different dynamics, vendors naturally pick different field names: TI may export V_SOURCE, V_OC_RATIO, INPUT_POWER; ST may export MPPT ENABLE, K FACTOR; Microchip may export just a consolidated HARVEST STATUS. This is why we explicitly say: “Cloud-side telemetry mapping must be updated before using cross-brand alternatives.”

BOM remarks to pre-fill:

• Record tested source type (PV / TEG / Vibration) in the BOM for purchasing.
• Cloud-side telemetry mapping must be updated before using cross-brand alternatives.
• Do not replace PV/TEG-specific harvesters with generic single-cell linear chargers.

Ultra-low-VIN cold-start architecture

Harvesting sources like indoor PV, low ΔT TEG and vibration/piezo often cannot supply enough power to let the main MPPT loop run immediately. If we wait for the MPPT loop to be ready, the system may never wake up. That is why a harvesting charger inside the BMS charging branch must include a separate cold-start path that can start from 80–200 mV even if its efficiency is poor.

The canonical structure is: Source → cold-start boost → small buffer → main MPPT / main charger → storage. The cold-start path only has one job: wake the system. After the system is alive and the source voltage is high enough (typically > 400 mV), the charger switches to the high-efficiency MPPT path.

Because this is a low-power, harvesting-only topic, we do not talk about automotive 12 V/24 V cold-crank, we do not talk about HV insulation or leakage monitor start-up, and we do not talk about traction-battery wake-up. We only describe “how to wake a micro harvester”.

Reference architecture

• Source (PV / TEG / Vibe) — unstable, low voltage, high impedance.
• Cold-start boost — low efficiency, but starts from 80–200 mV so the logic / charger core can power up.
• Small buffer / reservoir — a capacitor or thin-film cell that provides a short stable window.
• Main MPPT / main charger — high efficiency, enabled only when VIN is high enough (> 400 mV).
• Storage (thin-film / supercap) — for the actual load / edge node.

BOM-level remarks (must be logged)

These lines must appear in the BOM so that purchasing cannot silently replace the IC with a non-cold-start part:

• “Do not approve harvesting chargers without a cold-start path for PV/TEG.”
• “Record measured cold-start VIN and time in BOM for cross-brand alternatives.”
• “Cold-start path efficiency may be lower than main MPPT path; do not replace with generic buck for efficiency only.”

MPPT / input-power optimization for micro sources

For low-power energy-harvesting chargers, MPPT is not an optional feature. It is the only way to keep the source from collapsing and to extract enough energy to make telemetry and storage updates meaningful. Because we need to support cross-brand substitutions across TI, ST, NXP, Renesas, onsemi, Microchip and Melexis, the MPPT mode, input power and source voltage must be exposed to the edge / cloud.

Three MPPT strategies to support

1) Fixed-ratio / fractional VOC (PV) — simple, low overhead, good for indoor or slowly changing light. Usually exposed as VOC_RATIO or K FACTOR.

2) Perturb & Observe (slow environment) — better tracking when the available power is higher or when the environment changes over seconds. Common failure: step size too large → early/late light oscillation.

3) Input-current / input-power limited (TEG / Vibration) — keeps the source from being overdrawn. This is the most important one for TEG and piezo. It must be telemetered because different vendors call it different names.

Why it must be telemetered

When purchasing replaces a TI part that reports INPUT_POWER with a Microchip part that reports HARVEST STATUS, the cloud must know which MPPT mode is active to map the payload correctly. Therefore we repeat the rule: “Charger / gauge must expose charging state and MPPT zone to edge gateway.”

Typical micro-source MPPT failures

• MPPT step too large → early/late light oscillation (solution: reduce step, fall back to VOC-ratio).
• MPPT period too fast → charger steals energy from its own storage (solution: lengthen period or run only when storage voltage is high enough).

Purchasing notes to add:

• “MPPT mode / state must be readable for cloud-side mapping; parts without MPPT telemetry are not approved.”
• “When replacing PV-oriented harvesters, keep VOC-ratio / K-factor field mappable.”
• “When replacing TEG / vibration harvesters, keep input-current / input-power limit fields equivalent.”

Micro-power storage: thin-film, supercap, small Li and protection hooks

Energy-harvesting chargers in a BMS-like charging branch do not always feed a Li-ion battery. Many nodes only need to upload data once per cycle, survive intermittent power or deliver a short burst of energy. In these cases we must choose between thin-film cells, supercapacitors, and small Li-ion cells, and we must log that choice into the BOM so that purchasing cannot swap to a high-leakage device that will drain the harvested energy.

Use this rule across all seven brands: “Storage device type (thin-film / supercap / small Li) must be aligned with charger’s leakage and OVP profile.”

Thin-film storage

Thin-film cells have very low leakage and moderate voltage (typically 3.0–4.1 V) but limited capacity. They are ideal for ultra-low-power sensor / telematics nodes that harvest for minutes and then send a short packet. You can pair them with energy-harvesting chargers that support very low input and have configurable over-voltage: TI BQ25570 / BQ25505, ST SPV1050, Renesas ISL9205A.

BOM example:

• storage_type = thin-film
• Vstor_meas = 3.8 V
• I_leak@25°C = 0.6 µA
• charger_PN = TI BQ25570 or ST SPV1050

Supercapacitor storage

Supercaps deliver high burst current but have higher leakage and non-ideal ESR. In micro-harvesting applications this leakage can be larger than the harvested power, leading to endless reboots. That is why we must measure and record the actual leakage of the selected supercap and make sure the charger’s OVP limit matches the cap.

Typical ICs to pair with supercaps:

• TI BQ33100 (supercapacitor manager with capacitance / ESR estimation)
• Microchip MCP73871 (when you add a controlled path to the cap)
• onsemi NCP1854 with RC / ideal-diode front to the cap

If supercap leakage ≥ harvested power, node will reboot endlessly — measure and record I_leak.

Small Li-ion storage

When the node must survive the night, run firmware updates or sustain a sensor for longer periods, a small Li-ion cell is appropriate. In this case, the energy-harvesting charger must obey temperature, lifetime and protection rules. Suitable parts include: NXP MC34673, Renesas ISL9205A, Microchip MCP73871, onsemi NCP1854 / NCP1851.

Add to BOM: “Li-ion option → log charge voltage, charge current limit, and storage temperature window.”

Protection hooks in harvesting context

This page only talks about harvesting-level protection, not pack-level FETs. Typical hooks:

• Input OR-ing / reverse current block (prevent storage from feeding PV/TEG backward)
• Storage OVP (thin-film vs supercap have different max voltage)
• Storage UVLO (avoid over-discharge of thin-film / small Li)
• Optional current sensing (Melexis MLX91218-LF) to monitor leakage / burst current

Seven-brand material list (for this page)

• TI: BQ25570, BQ25505, BQ33100
• ST: SPV1050
• NXP: MC34673
• Renesas: ISL9205A
• onsemi: NCP1854, LC709203F (telemetry)
• Microchip: MCP73871
• Melexis: MLX91218-LF (current / leakage supervision)

System / edge / cloud exposure (telemetry-first design)

Low-power harvesting chargers from TI, ST, NXP, Renesas, onsemi, Microchip and Melexis do not expose the same field names for MPPT state, source voltage or storage voltage. To keep this branch cross-brand substitutable, we always require: “Charger / gauge must expose charging state and MPPT zone to edge gateway.” and “Cloud-side telemetry mapping must be updated before using cross-brand alternatives.”

This chapter defines the minimum field set an edge device must send to the cloud so that a harvester IC can be replaced without changing the whole application.

Minimum fields to report

• source_v / harv_vin — actual voltage at the harvesting input.
• mppt_state / mppt_mode — VOC-ratio, P&O, or current-limited.
• input_power_est — optional, but recommended for PV/TEG trend analysis.
• storage_v — thin-film / supercap / small Li voltage.
• charge_allowed / chg_state — is charging currently enabled.
• cold_start_flag / start_vin — to debug indoor-light / low-ΔT startup failures.
• storage_type — from Chapter 5, to match OVP/leakage.

Edge device must support buffered upload for temporary disconnection.

Brand-to-schema mapping examples

The following typical ICs can be mapped into that minimal schema:

• TI: BQ25570 / BQ25505 → VSTOR → storage_v, VIN_DC → harv_vin, and MPPT settings → mppt_mode.
• ST: SPV1050 → VOUT / MPPT / BAT_OK → map to storage_v, mppt_state, charge_allowed.
• NXP: MC34673 (no native harvesting telemetry) → use MCU ADC to sample PV/TEG and storage then upload as the same fields.
• Renesas: ISL9205A → expose input OK, charge status, temperature → map to charge_allowed, storage_v.
• onsemi: NCP1854 + LC709203F → I²C gives VBAT, status, RSOC → map to storage_v, chg_state, input_power_est.
• Microchip: MCP73871 → PG, STAT, VBAT → map to charge_allowed, storage_v.
• Melexis: MLX91218-LF on the storage path → report leak_current / burst_current to the same schema.

Small-batch procurement & cross-brand alternatives (harvesting edition)

Low-power PV/TEG/vibration harvesting chargers are very easy to be “simplified” by purchasing. To keep this branch cross-brand and still telemetered, we must block three typical mistakes, provide three alternative paths, and name the seven brands in the BOM.

Typical mistakes in small-batch runs

• 1) Replacing “PV/harvesting” with a generic linear charger. This removes cold-start and MPPT zones → indoor light and small TEG never wake.
• 2) Ignoring cold-start voltage. Purchasing buys a part with 400–600 mV start but the node needs 100–150 mV → always offline.
• 3) Buying another brand “with MPPT” but without telemetry. Cloud mapper cannot tell which MPPT zone is running → analytics broken.

BOM (required): “Do not approve non-reporting harvesting chargers.” / “Record source type (PV/TEG/Vibe) and measured cold-start VIN in BOM.”

Three alternative paths

A → A (same brand, cold-start + telemetry kept)

Stay inside one brand and choose a pin-compatible or same-family device that still supports cold-start + status reporting.

• TI: BQ25570 → BQ25505 (same ultra-low-power harvester line)
• ST: SPV1050 → SPV1040 (both PV/harvesting with MPPT)
• Microchip: MCP73871 → MCP73872 (keep STAT/PG for telemetry via MCU)
• onsemi: NCP1854 → NCP1851 (I²C based, status readable)

A → B (cross-brand, cloud mapper must be updated)

When TI ⇄ ST ⇄ Microchip ⇄ onsemi substitutions happen, the field names change. You must update the cloud mapper first.

• TI BQ25570 ⇄ ST SPV1050
• TI BQ25505 ⇄ Microchip MCP73871 (MCU must pack Vbat/STAT into telemetry)
• ST SPV1050 ⇄ onsemi NCP1854 (NCP1854 reports via I²C)
• Renesas ISL9205A ⇄ NXP TEA2095T (both can support low-power solar)

BOM add: “Cross-brand alternatives are limited to TI / ST / NXP / Renesas / onsemi / Microchip / Melexis; update telemetry mapping before use.”

A → A (downgrade, local-only)

If the node never uploads harvesting analytics, you may use a lower-feature, low-VIN device. Mark it clearly: “local-only / no cloud analytics”.

• TI BQ25570 → TPS61291 (low-VIN boost, but no full MPPT)
• Microchip low-power boost + small charger
• onsemi NCP1402 / NCP1529 + small Li charger

Seven-brand material focus

TI: BQ25570, BQ25505, BQ25504
ST: SPV1050, SPV1040
NXP: TEA2095T
Renesas: ISL9205A
onsemi: NCP1854, NCP1851
Microchip: MCP73871, MCP73872
Melexis: MLX91218-LF (current / leakage monitor on harvesting branch)

Validation & troubleshooting for low-power harvesting nodes

Low-power harvesting designs fail differently from high-power BMS branches. We must test cold-start, MPPT stability at low source levels, storage leakage vs harvested power, and telemetry completeness, then write the test results into the BOM to prevent wrong substitutions.

Validation items to write into BOM

• Cold-start test: sweep 80 / 100 / 150 / 200 mV, record start VIN and time, and source type (PV / TEG / Vibe).
• Low-light / low-ΔT MPPT stability: check if MPPT oscillates; reduce step or slow period if needed.
• Storage leakage vs harvested power: measure I_leak of thin-film / supercap / small Li; confirm harvested power is higher.
• Telemetry completeness: harv_vin, mppt_state, storage_v, charge_allowed, cold_start_flag all arrive at edge / cloud.

BOM note: “Write test results into BOM to prevent wrong substitutions.”

Troubleshooting patterns

Focus on harvesting-specific failures, not high-voltage or traction-battery problems.

Seven-brand test references

TI: BQ25570, BQ25505
ST: SPV1050
NXP: TEA2095T
Renesas: ISL9205A
onsemi: NCP1854, LC709203F
Microchip: MCP73871
Melexis: MLX91218-LF

BOM remarks & procurement hooks (harvesting-specific)

This page collects all BOM sentences scattered across Chapters 1–8 of the “PV/TEG/Vibration energy-harvesting charger” branch. These remarks are written for purchasing so they will not replace a harvesting charger with an ordinary single-cell linear charger, and so they keep the cold-start and telemetry features needed by the cloud mapper.

Scope: harvesting charger branch only. Do not use for pack-FET sizing, main DC/DC selection or EVSE/charging-gun protocol.

Extended harvesting BOM lines

Seven-brand BOM scope (harvesting)

TI: BQ25570, BQ25505, BQ25504
ST: SPV1050, SPV1040
NXP: TEA2095T
Renesas: ISL9205A
onsemi: NCP1854, NCP1851
Microchip: MCP73871, MCP73872
Melexis: MLX91218-LF

Recommended topics you might also need

• Nano-Leakage Charger (Wearables)
• Supercap Charger / Balancer
• Single-Cell Linear Charger
• Edge–Cloud Battery Analytics
• Formation/Cycler Interface IC

FAQ — Harvesting charger branch

All questions below apply only to the PV / TEG / vibration energy-harvesting charger branch inside the Battery Charging / Gauging / Protection / BMS template. Do not use these answers for multi-cell charger controllers, USB-C sink + charging, or pack-FET topics. Text here must stay the same as the JSON-LD block below.