Battery: Ampera‐e 64 kWh does not balance cells

[vcovtun-svg]

Hi!
Everything is connected according to the scheme, the battery is charged and discharged, but each time there are more and more deviations between the cells. Under what conditions should the cells start balancing? Chevrolet bolt battery with original BECM. Thank you.

[v0van]

Good afternoon. I'm also connecting this battery to a solar inverter. Has this cleared up anything about balancing this battery? Or will I need to disconnect the contactors to initiate the balancing process, like with the Tesla Model 3(Y)?

And a related question: Should I apply 12V to pin 5 (x358 connector), or is there a different way?

[server2025]

Has the Chevrolet Bolt battery balancing problem been resolved?

[vcovtun-svg]

Balancing does not turn on, the author has given up on this problem.

[john-alfred]

Has anyone tried to charge the battery to near or full soc to see if this triggers the bms to balance the cells?
I think this is refered to as bleed balancing.

[vcovtun-svg]

A CAN command is required to start cell balancing. This information is not publicly available. Therefore, the Bolt battery will not be balanced.

[john-alfred]

Oh i see, thats unfortunate. How badly balanced is your pack running? im currently at a deviation of 14 mV.

[vcovtun-svg]

I’m currently have 185mV ;)

[john-alfred]

Oh wow, is that concidered within "safe" operational limits?

[finepos]

Empirical confirmation: standalone Bolt BICM never balances cells

Following this discussion. Ran a Chevrolet Bolt 64 kWh LG N2.2 pack standalone (no vehicle BECM) in stationary inverter use for 49 days and systematically polled UDS PID 0x431C (HYBRID_BATTERY_CELL_BALANCE_STATUS).

Result: 4,113 polled responses, 100 % status = 0 (idle).

Includes extreme conditions — cell delta peak 150 mV, cell min 3.265 V at deep discharge.

Conclusion: standalone BICM behaves as a sensor + reporter only. Balance decisions live in the missing BECM master. Empirically refutes any "maybe BICM balances at high SOC / low SOC / extreme delta" hypothesis.

Full dataset (CC0 public domain)

https://github.com/finepos/bolt-bicm-empirical-data

13 CSV datasets covering 49 days of standalone operation:

• 01 — PID 0x431C balance status time series (4,113 samples, 31 h)
• 02 — Raw responses for all polled PIDs (0x431C, 0xC218, 0x40D4, 0x438B, 0x40D3, 0x428F, 0x4290, 0x8043)
• 03 — 1,980 extreme imbalance events
• 06 — Per-cell rank stability across 99k samples — position Compatibility with Other Inverters #12 at maximum 48 % of time, position Add timeout to CAN write to prevent crashing #49 at minimum 19 % (persistent positional extremes without balancing)
• 09 — Cell-min voltage histogram showing pack operating regime
• 12 — Raw 60-second CAN bus capture, 31,800 frames (every frame on BICM-side bus including the 0x270/0x272/0x274 BalancingSwitches frames that have only a code comment in the current codebase but no decoded interpretation)
• 13 — Per-CAN-ID inventory summary with frequencies and first-seen payloads

PID anomalies needing community decoding

From our data:

• 0x40D4 INTERNAL_CURRENT — narrow range -11823..-11812 across 31 h including active ±10 A operation. Does NOT track instantaneous current as the name suggests. Likely a register value.
• 0x438B HV_BUS_VOLTAGE — BICM never responds (0 replies across 4,113 polling cycles). Wrong PID number, wrong service, or requires UDS Security Access?
• 0x428F / 0x4290 5V_REF_1/2 — only 2 distinct values across 31 h (3001 / 3020 mV). Does not match expected ~2,500 mV for Uc/2 reference. Scaling formula wrong, or these PIDs are not 5 V refs?
• 0x40D3 5V_REF_MAIN — returns 4,809 mV, consistent with name.

Unknown periodic frames in CAN capture (dataset 12)

In the 60 s standalone capture, periodic frames appear that are not documented in BOLT-AMPERA-BATTERY.cpp:

• 0x091, 0x0D1, 0x111 at ~1.2 Hz
• 0x308 at 10 Hz

Anyone seen these elsewhere?

The big ask

If anyone has access to a working in-vehicle Bolt (not the recalled pack) and can tap K16 X8 internal CAN (pins 4/5 or 14/15 per openinverter t=4370) — even a 60-second capture during a normal home charge session would unblock the entire community. Diffing it against our standalone baseline (dataset 12) would directly identify the balance command frame.

License CC0, replication welcomed.

[vcovtun-svg]

I have a bolt, I have a cardaq 3 plus scanner. Write down - what to do and how to use what software to capture command packets when charging. I will make and send the log.

[finepos]

Replying to recent posts:

@v0van — about disconnecting contactors

Based on my 49-day dataset, unfortunately the answer is no — standalone BICM never balances regardless of contactor state. I monitored UDS PID 0x431C continuously across all operating modes (full charge, deep discharge, idle, active charge, active discharge) — it returns 0 (idle) in every single one of 4,113 polled samples.

Disconnecting contactors won't initiate balancing because the BICM never receives the command from BECM that would trigger it. The balance logic lives in the missing BECM master, not in the BICM. External active balancer hardware (NEEY/Heltec) is the only practical workaround until BECM emulation is cracked.

@john-alfred — about top-balance / bleed at high SOC

Correction to earlier numbers — I had miscalculated histogram percentages, here are the verified values from dataset 09:

• ~60 % of operating time at cell min ≈ 3,500 mV (mid-SOC band)
• ~10 % at cell min ≥ 3,750 mV
• ~3.4 % at cell min ≥ 3,950 mV (near full charge)

So the pack DOES spend meaningful time at high cell_min — full-SOC data exists in the general telemetry record.

However — and this is the important caveat — extended polling of PID 0x431C was only active during a narrower window (2026-05-09 → 2026-05-10). During that window, cell_min ranged 3,265–3,563 mV. So while the 0x431C status was confirmed 0 across 4,113 samples in that range, I do NOT have PID 0x431C readings at cell_min > 3,563 mV.

What I can say:

• BICM doesn't auto-balance in the 3,265–3,563 mV range (verified)
• BICM doesn't auto-balance in any operating mode I logged via PID poll (verified)
• Behavior at cell_min > 3,563 mV is untested in this dataset

The bleed-balance-at-high-SOC hypothesis remains open. Testing it conclusively would need PID 0x431C polling while pack is sustained near 100% SOC. If anyone has that data — would help close the question.

@vcovtun-svg — THIS WOULD BE HUGE. Thank you for offering. Capture protocol below.

What bus to capture

CarDAQ-3 Plus is great for OBD-II / DLC bus, but the BECM↔BICM internal CAN is not at OBD-II — it's on the K16 X8 connector behind the rear passenger area. Per openinverter t=4370:

• Pins 4 & 5 or pins 14 & 15 of K16 X8 connector (CAN-H / CAN-L twisted pair)
• 500 kbps, CAN-FD-capable bus (corrected: my standalone capture shows is_fd=false on every observed frame so the BICM mostly emits classic-format frames on this bus, but use a CAN-FD-capable sniffer just in case BECM emits FD frames during in-vehicle operation. Hardware suggestion: anything with MCP2518FD or Kvaser/PCAN-FD chipset.)
• Internal to the pack assembly, not exposed at the DLC port

You'll need a breakout cable or wire-piercing probe to tap into those pins, then connect either:

• Option A: CarDAQ-3 Plus in J2534 pass-through mode (if it supports raw CAN capture on aux channel — check J2534 software like DrewLinQ or HP Tuners' SCT)
• Option B: Any CAN sniffer with the right pin connection — PCAN-View, SocketCAN dongle, Vector CANalyzer, even a $30 OBDLink with custom firmware. Often easier than getting CarDAQ to do raw CAN

Two recommended capture scenarios

If possible, both — but either alone is transformative:

1. "Charging from low SOC" — plug in L1 / L2 charger at SOC ≤ 30 %. Capture from plug-in moment through first 5 minutes. Most likely time for BECM to send balance setup commands.

2. "Near-full SOC" — last 5 minutes of a charge session approaching 100 % / charge termination. Tests @john-alfred's bleed-balance hypothesis directly.

Even 30 seconds of either would change what the community can do.

Output format — any of these works

• .asc (Vector ASCII)
• .blf (Vector binary)
• .log (candump-style)
• .csv with columns: timestamp, can_id_hex, dlc, data_hex
• Raw hex dump

Where to share

• Attach file directly to a comment in this discussion (GitHub allows ≤ 25 MB)
• Or open an issue/PR on my data repo — I'll merge
• Or any cloud share (Dropbox / Drive / etc.)

What to look for (optional, if you want to peek first)

Diff your in-vehicle capture against my standalone baseline (dataset 12):

• Frames present in YOUR capture but NOT in mine → BECM-originated. These are the balance command candidates.
• Most likely candidate: 0x20E (Battery-Emulator TODO calls it "Hybrid balancing request HV", but nobody has captured one)
• Also worth diffing the payload bytes of frames present in BOTH captures — especially 0x270 / 0x272 / 0x274 (BalancingSwitches). The BICM-side IDs probably emit different payloads when BECM is actively commanding balance.

This single capture could unblock years of community work. Thank you for taking this on.