Formation/Cycler Interface IC (Charging-Domain Bridge)

Scene definition and scope (formation / cycler branch)

This page describes the production / lab formation and cycler branch of your battery flow, not the in-field BMS charging chain that runs in the vehicle or device. In this branch, a formation rack or cycler must drive many cells/fixtures at the same time, using the same pulse or polarization profile, and then return measurement data into the same telemetry schema that your main “Battery Charging / Gauging / Protection / BMS” hub already uses.

Because formation/cycler runs on racks with long cables and different grounds, this branch needs multi-channel, hardware-synchronized execution, galvanic isolation, and telemetry-friendly payloads. The device that makes this possible is the Formation/Cycler Interface IC — a mid-layer IC that packages multi-channel DAC/ADC, pulse/polarization profile execution, and isolated communications.

What this page covers

• Production / lab context: many slots (8–32) doing the same formation or cycler profile.
• Why synchronization between DAC output and ADC sampling is mandatory to compare cells in the same batch.
• Why this data must enter the existing charging/BMS telemetry table so the cloud only maintains one schema.
• What the Formation/Cycler Interface IC actually does: multi-channel DAC/ADC + profile engine + isolated comms.

What this page does not cover (anti-overlap)

• Not the online, in-field flow of Multi-Cell Charger Controller (2S–6S) — that belongs to runtime charging.
• Not Insulation / Leakage Monitor (HV) — that is the HV safety domain.
• Not USB-C Sink + Charging Coordination — that is front-end power negotiation.
• Not pack-FET thermal / parallel / discharge topics — those stay in protection/pack switch pages.
• Not generic DC/DC theory — we only say “DC bus feeds the interface IC”.

Example you should write into the final article: “On a 16-slot formation rack, the line pushes a 200 ms polarization pulse to every slot at the same time. Within 20 ms after the pulse, the interface must read back voltage, fixture temperature, slot/channel ID and the active_profile_id, then upload it to the same charging/BMS telemetry table. If we do not force this data into the common schema here, later subpages will collide.”

Layered architecture: formation bus vs charging domain

To avoid sibling-page overlap, the whole formation/cycler topic is split into three layers. This page only expands Layer 2 — the one that holds the synchronized multi-channel DAC/ADC, profile execution and isolated communications. The upper controller layer and the lower fixture/cell layer are mentioned only to show context.

Layer 2 must use isolated communication because the rack power ground, fixture ground, and PLC ground are not the same. Without isolation, noise and surge from the formation rack would be injected back into the upper controller and potentially into the charging domain.

All formation/cycler data is pushed into the same charging/BMS telemetry table so that later analyses such as “factory formation results → in-field fast charge behavior” do not require schema joins. Instead of inventing new fields, we reuse charging fields like charge_state, jeita_temp, channel_id, and fault_code, and tag them with a formation source.

At this interface layer, stay inside the seven vendor families so that timing, SPI/CAN frames and safety notes are all documented and can be mapped: TI (ADS131 / AMC13xx + ISO77xx), ST (L9963E + STISO), NXP (MC33771/72 + isolated CAN), Renesas (ISL78714 / RAA BMS front-end), onsemi (NCV BMS monitor + isolated transceiver), Microchip (MCP356x + MCP47xx + MCP256xx), Melexis (temperature / sensing for formation).

Do not replace this layer with generic MCU + multi-channel ADC demo boards. This layer must use a documented and synchronized measurement frame so cloud-side charging/BMS mapping stays valid.

Channel organization, synchronization and profile execution

Formation/cycler lines deliver value only when all cells in the same batch do the same action at the same time so the operator or cloud can compare them. That is why the Formation/Cycler Interface IC is not just “a board with many ADC/DAC channels”, but a device that can execute profiles in lockstep across all channels.

If one or two channels are delayed by even a single sampling instant, the polarization voltage of those slots will not line up with the others and the cloud analytics will see noise instead of real dispersion.

Profiles this layer must support

• CC charge segment – push current to all active slots at the same timestamp.
• CV hold segment – all slots switch to CV together so the rest window lines up later.
• Pulse / polarization segment – short, higher current pulses that absolutely require hardware-synchronized DAC updates.
• Rest & sample segment – the place where many ADCs take the real IR / polarization decay measurement.
• Thermal derating segment – when fixtures are hot, the whole batch is derated together instead of only one slot.

All these segments should be driven from the same hardware time base. In practice that means three things are triggered from the same timer: (1) DAC update, (2) ADC sampling, and (3) the isolated frame that reports results upward. If the timer is not shared, in a 16-channel system you will see 1–2 channels permanently shifted by one sample.

Do not replace the interface IC with a generic multi-channel DAQ board. Without a profile engine you can only push loose CC/CV commands; without synchronization you cannot align formation data with the charging-domain timeline; without per-channel fault flags the cloud cannot tell which fixture or slot actually dropped.

Formation is per-channel. Averaging across 16 slots hides slot-level faults and will break the cloud analytics later. The whole point of keeping channels synchronized is to let you say “slot 7 was 5 mV weaker than the other 15 at t2”.

Because all channels run on a unified hardware timeline, the formation data can later be packed into chargingTelemetry.* without creating vendor-specific exceptions.

Isolated communications for formation/cycler lines

Production racks run at higher power, with long fixture cables and multiple grounds (rack, fixture, PLC). Noise, surge and ground potential differences are all larger than in an in-field charger. Therefore, the interface IC in this branch must include or support galvanic isolation to protect both the controller and the charging/telemetry domain.

Typical communication paths at this layer

• SPI / I²C → isolation → MCU / PLC – for racks that use a local microcontroller to drive formation.
• Isolated CAN / FlexRay → line controller – for stations that are already on an industrial bus.
• UART / RS-485 → isolation → EtherCAT / gateway – for retrofit or gateway-based production lines.

The isolation should sit between the formation controller and the Formation/Cycler Interface IC, not on the cell/fixture side. The cell side is the high-energy side and the BMS/AFE devices there (TI AMC, Renesas ISL, NXP BMS AFE) are already designed to tolerate higher common-mode conditions. What we must protect is the upstream telemetry and control that will be merged with the charging domain.

After cross-brand replacement, the cloud-side telemetry mapper must be updated so TI, ST, NXP, Renesas, onsemi, Microchip and Melexis payloads do not get mixed. Different vendors send slightly different frames; without mapping updates the cloud would treat them as one and analytics would be wrong.

Procurement rule: Interface IC for formation/cycler must include or support galvanic isolation; do not replace with non-isolated DAQ or MCU boards, even if the pin count matches. Use only TI / ST / NXP / Renesas / onsemi / Microchip / Melexis isolation and BMS-front-end parts to keep protocol docs aligned.

Telemetry / Cloud mapper connection to charging schema

This chapter narrows the formation/cycler payload into the same charging / BMS telemetry table already used by your Battery Charging / Gauging / Protection / BMS hub. We do it with an explicit source → target mapping so that every new formation vendor still produces data that your cloud can read.

Formation fixtures are also temperature-sensitive, but instead of inventing new telemetry fields, we reuse the existing JEITA temperature slots and tag them with source=formation. One table, multiple sources — the cloud knows where the sample came from.

Cross-brand replacement flow (must follow this order)

1. Purchasing proposes to replace a TI-based formation interface with an NXP, Renesas or onsemi device.
2. Engineering compares the new payload (registers / frame) against the above mapping and confirms 1:1 match.
3. Cloud/data team adds a row in the telemetry mapper table: vendor=…, model=…, mapping=formation-to-charging.
4. Only after the mapper row is present, purchasing may place the order.

If you skip this mapping step, later CSV exports will mix formation-time data with in-field charging data and your BI/dashboard will be wrong.

Vendor payload examples (to be mapped)

Small-batch procurement & cross-brand alternatives (7-brand limited)

This chapter turns the technical rules into actual BOM text. The goal is to stop small-batch purchases from downgrading isolation, synchronization or telemetry reporting. Swapping to a cheaper DAQ may still measure voltage, but it breaks the binding to the charging telemetry schema.

Three real “stealth swap” cases to block

Allowed cross-brand movement is only inside the seven brands you defined: TI ↔ ST ↔ NXP ↔ Renesas ↔ onsemi ↔ Microchip ↔ Melexis, and only when all four conditions stay the same: (1) channel count not reduced, (2) isolation rating not reduced, (3) hardware sync/profile engine not removed, (4) payload still recognized by the mapper from Chapter 5.

Concrete IC families to keep in BOM

BOM remark to keep: “Charger / gauge / formation interface must expose charging-compatible telemetry; parts without reporting capability must not be approved.”

BOM Remarks Template

This section consolidates the critical BOM remarks from earlier chapters into a clear checklist format, intended to ensure procurement aligns with the established standards.

This section is for procurement only. Please copy and include these remarks in the BOM to ensure compliance with formation/cycler interface specifications.

• Formation/cycler interface IC must provide synchronized multi-channel DAC/ADC execution for pulse/polarization profiles. Do not approve non-synchronous DAQ boards.
• Galvanic isolation between the station controller and the interface IC is mandatory for this line. Alternatives without isolation are not acceptable.
• Telemetry from formation/cycler must map to the site’s charging/BMS schema before release. Cross-brand replacements require cloud mapper update.
• Vendor rotation is limited to TI / ST / NXP / Renesas / onsemi / Microchip / Melexis for this interface position.
• Do not downgrade formation interface parts that support JEITA-compatible temperature reporting to fixed-temperature devices.

For small quantities or cross-brand validation, submit your BOM and we will map the telemetry for you.

FAQ + JSON-LD Mapping

Below are the 12 FAQs with answers related to formation/cycler interface IC and its integration with the charging schema. These answers provide clarity on common queries related to sync, isolation, telemetry mapping, and procurement.