Jaguar I-Pace battery BMS

[yasko]

Here, I will describe my findings regarding the Jaguar I-Pace battery BMS. The goal is to reuse stock BMS for the ESS project.

There is one master BMS and six secondary modules. Each secondary has two identical sections: BMS chip (76PL455ATQ) and MCU for communication. There is galvanic isolation between the BMS IC and MCU. (Picture)
Each section monitors nine cells (3 battery modules) or 18 cells for one secondary module. The I-pace battery is a 108S configuration consisting of 36 battery modules. Part of the BMS schematic is here.

There is an internal CAN bus between the master and secondary modules at 500kbps speed. The ISA current shunt is also connected to this bus.
As the first step, I started exploring the secondary modules. There is a 20-pin connector for power supply and communication. The mating part is Molex 34824-0204.
After attaching 12 V to the module, it starts sending CAN data (it requires a CAN bus termination):

(000.085557) can0 124 [8] 39 1E 01 FF 6F 00 FF C8
(000.000039) can0 123 [8] FF FF DF FF 3F FF FF FF
(000.000535) can0 121 [8] 1F FF 1F FF 1F FF FF FF
(000.000031) can0 122 [8] 3F FF 9F FF 1F FF FF FF
(000.011435) can0 114 [8] 39 1E 01 FF 6F 00 FF 78
(000.000220) can0 113 [8] FF FF DF FF 3F FF FF FF
(000.000222) can0 111 [8] 1F FF 1F FF 1F FF FF FF
(000.000282) can0 112 [8] 3F FF 9F FF 1F FF FF FF

No battery module is connected in this test. The data repeats every 100 ms.

The next step was to connect three battery modules. (I have only four available at my lab) There is a specific connection order, and I followed the BMS schematic. After that, the data looks promising:

can0 114 [8] 39 1E 01 58 70 64 3F 10
can0 113 [8] 0E F7 0E F8 0E F8 39 39
can0 111 [8] 0E F5 0E F5 0E F6 39 39
can0 112 [8] 0E F5 0E F5 0E F6 39 39

I've filtered CAN data only from the section with connected cells, and it was easy to find that frames 111, 112, and 113 contain cell data. The first six bytes in each frame are three cell voltages, and the last two are temperatures.
The cell voltage encoding is straightforward: 0xEF7 = 3831mV; I'm unsure if the temperatures 0x39 = 57 may be divided by four to get the actual temperature.
For frame 114, I can say nothing except that byte 8 is alive counter. I will do more testing, and now I'm attaching one log file with live data.
And one picture of the device under test:

To be continued...

[Jacobsmess]

This is really interesting. One thing I wondered was if the BMS would work fine with fewer modules, (32 rather than 36 in my case) and your findings suggest so if I'm interpreting them correctly.

[tom91]

I'm unsure if the temperatures 0x39 = 57 may be divided by four to get the actual temperature.

You say in your lab is it heated? -40 is a normal way of declaring temps automotive

[yasko]

I've rechecked things and can confirm that the temperature is encoded with an offset of 40, as Tom91 suggested.
We need to subtract this value to get the actual cell temperature.

I think it is possible to use fewer modules, but the number must multiplе by 3, e.g., 27,30,33, etc. Each BMS circuit is intended to work in a 9S configuration. For 32 modules, one BMS must be in 6S configuration, and I'm unsure whether it will work correctly.

[yasko]

A brief update: I've started experimenting with the primary BMS regarding cell balancing.

To wake up the BMS, it needs a connection to an external CAN bus (V_CAN). There is no need to send specific data; connect a CAN adapter.
Then, the BMS supplies power to secondary modules (CSC) via dedicated pins, and there is CAN traffic on the internal CAN bus. I'm attaching a startup-up log without CSC modules connected to the bus.

Here is a description of the data connector of the battery: Jaguar battery pinout
The signals are also available directly on the primary BMS module.

The next step will be to connect some CSC modules and log the data. Restoring the full battery connection will take time.

[yasko]

A few weeks ago, I attempted to reconnect the whole battery:

This enormous battery has many wires, and I only had a day to play with it, so reconnecting was incomplete.
I've captured some logs and am sharing them. Some of the findings so far:

* The central BMS probably requires a specific CAN frame to go into an operational state. It wakes up on any CAN frame and starts sending data, but after a while, it stops for a moment and then starts again. (master_CAN_ipace.txt). This bus needs external termination.

* Each secondary module transmits data with its frames: the first one is 0x111-0x114, the second is 0x121-0x124, and so on. There are two logs on the internal CAN bus. The difference is that I swapped the first and second modules.
The first module was out of balance, and I expected some balance commands.

Some frames may be related to the balance commands, and I will experiment with CSC modules when I have more time.