search

LibreSolar / bms-firmware

Firmware for LibreSolar BMS boards based on bq769x0, bq769x2 or ISL94202
https://libre.solar/bms-firmware/
Apache License 2.0
154 stars 70 forks source link

Tested the BMS C1 v0.3 using a load tester and tested for cell level protection. #35

Open Ananyaaynana opened 12 months ago

Ananyaaynana commented 12 months ago

The tests were done in two parts.

Part 1

The first test was done using a load tester. The electronic load tester used is RePower Battery Test System with a capacity of 120V, 100A. A LFP battery pack of 52V and 6 Ah capacity having the configuration of 16s1p was used. The BMS was mounted on a heat sink. Each cell in the battery pack was connected to the BMS’s cell connector and the battery pack’s positive terminal was connected to the BAT+ of the BMS and the battery pack’s negative terminal was connected to the BAT- of the BMS. The electronic load was connected to the to PACK+ and PACK- of the BMS. The board was connected to a linux system using USB to UART connector.

The following tests were conducted:

Discharge overcurrent protection

Test procedure: The amount current drawn by the load was initially set to 6 A. The current drawn by the load was increased to 15 A. The cutoff value was set to 13.3A. Result: The discharge overcurrent is detected correctly and the BMS flags a discharge overcurrent error (8). The discharge MOSFET is disabled and the BMS is put in state 1 in which discharging is disabled and charging is enabled. Issue: The thingset command "!Device/xReset" causes the BMS to become unresponsive. Had to reflash the code to return to normal execution.

Charge overcurrent protection

Test procedure: The charge current given to the battery was initially set to 6 A. The charge current given to the battery was increased to 15 A. The cutoff value was set to 13.3A. Result: The charge overcurrent is detected correctly and the BMS flags a charge overcurrent error (16). The charge MOSFET is disabled and the BMS is set in state 2 in which charging is disabled and discharging is enabled. Issue: The same issue with Discharge overcurrent protection.

Short Circuit protection

Test procedure: The discharge current given to the battery was initially set to 6 A. The charge current given to the battery was increased to 15 A. The short circuit limit set was 33.3A. Result: The short circuit is detected correctly and the BMS flags a short circuit error (4). The discharge MOSFET is disabled. Issue: Same as with Discharge overcurrent protection.

In all these tests reset was an issue. This board will be used in an Electric Vehicle and recovery method for charge overcurrent, discharge overcurrent does not seem feasible as its difficult to send a current of the opposite direction when the vehicle is in use.

Part 2

The second test is the individual cell protections. The cell connectors of the BMS are connected to the pack simulator. Cell 16’s positive terminal and battery packs positive terminal are connected to the BMS tester. Cell 1’s negative terminal and battery pack's negative terminal are connected to the BMS tester. B+ of the BMS tester is connected to BAT+ of the BMS.

Equipment used:

Cell Overvoltage Protection

Test method: Each cell is given a voltage of 3.3V and voltage is increased to 3.6V gradually. At the end, voltage is brought down to 3.5V which is the recovery voltage. Result: The overvoltage is detected correctly and the BMS flags a cell overvoltage error(2). The charge MOSFET is disabled and the BMS is in state 2 in which discharging is enabled and charging is disabled. After reaching voltages below the reset threshold of 3.5 V again, the BMS goes back to normal operation (state 3).

Cell Undervoltage Protection

Test method: Each cell is given a voltage of 3.3V and voltage is decreased to 2.5V gradually. At the end, voltage is increased to 2.6V which is the recovery voltage. Result: The undervoltage is detected correctly and the BMS flags a cell undervoltage error(1). The discharge MOSFET is disabled and the BMS is in state 1 in which charging is enabled and discharging is disabled. After reaching voltages above the reset threshold of 2.6 V again, the BMS goes back to normal operation.

Cell Overtemperature Protection

Test method: The cell temperature sensor is heated up by dipping in hot water heated above the required temperature threshold. Result: The overtemperature is detected correctly and the BMS flags a discharge and charge overtemperature (512 + 128). Both MOSFETs are disabled and the BMS is in state 0 where both charging and discharging is disabled.

Cell Undertemperature Protection

Test method: The cell temperature sensor is cooled down by placing it in ice. Result: The undertemperature is detected correctly and the BMS flags a charge undertemperature (256). Charge MOSFET is disabled and the BMS is in state 2 where charging is disabled and discharging is enabled.

Pictures

A few pictures from the test:

WhatsApp Image 2023-11-30 at 16 42 59 Snapshot of the individual cell protection test values. WhatsApp Image 2023-11-30 at 16 43 46 Connection of the board to the test system.

martinjaeger commented 12 months ago

Thanks @Ananyaaynana for providing your test results. I have taken the freedom to use some Markdown to format your text so that it is easier to read.

As a summary everything seems to work fine except for the following two points, correct?

  1. The device gets stuck when trying to reset it with !Device/xReset. This sounds like a bug.
  2. You would like to have a different method to reset the overcurrent protection, which would be a feature request.

Regarding the overcurrent reset method in an EV application: Which behavior do you suggest?

Ananyaaynana commented 12 months ago

Yes the two points you mentioned are correct. Regarding overcurrent behavior:

Discharge Overcurrent Recovery Two ways I understood from the BQ76952 technical manual

  1. Host can send a 0x009B OCDL_RECOVER() command.
  2. From the datasheet "If recovery is preferred based only on time, then the recovery based on charging current can be used, with the current threshold set to a small discharge current."

I believe the first method is better than the second.

Charge Overcurrent Recovery From the datasheet: "The device will recover (if configured for autonomous recovery) when the voltage measured on the PACK pin falls at least Protections:OCC:PACK-TOS Delta below the voltage measured at the top-of-stack for a duration of Protections:Recovery:Time"

This method is feasible when the board is used in an EV.

I forget to add that when we observed the reading of current in the thingset live publication it was off by 6% with respect to the value measured by the electronic load. Is the BQ76952 chip calibrated according to the calibration manual: https://www.ti.com/lit/an/sluaa32a/sluaa32a.pdf?ts=1700558725425

martinjaeger commented 12 months ago

Discharge Overcurrent Recovery Two ways I understood from the BQ76952 technical manual

  1. Host can send a 0x009B OCDL_RECOVER() command.
  2. From the datasheet "If recovery is preferred based only on time, then the recovery based on charging current can be used, with the current threshold set to a small discharge current."

I believe the first method is better than the second.

Under which conditions should that command be triggered? How do we know that the overcurrent condition is gone and it will not immediately happen again?

I forget to add that when we observed the reading of current in the thingset live publication it was off by 6% with respect to the value measured by the electronic load. Is the BQ76952 chip calibrated according to the calibration manual: https://www.ti.com/lit/an/sluaa32a/sluaa32a.pdf?ts=1700558725425

No, it's not calibrated at the moment. That would be a good enhancement, though.

I was thinking about a ThingSet command like !Cal/xCurrent [20] which would take the provided parameter (here 20 A as an example) and calculate the offset/gain based on the value measured by the bq chip. Of course one would have to apply exactly that provided value to the board and have an external measurement device with very good accuracy.

Do you have any other ideas how calibration could be done?

Ananyaaynana commented 11 months ago

Regarding discharge overcurrent: OCD3 is using the CC1 current measurement from the coulomb counter ADC. Since Coulomb counter integrates current measurements from 0 to t seconds. I believe OCD3 will be a better measurement of the overcurrent condition. EV manufacturers say that discharge overcurrent for a few seconds is needed to meet the demands of the rider. If OCD3 delay is set to say 5 seconds then after 1 second of recovery time the 0x009B OCDL_RECOVER() can be sent by the host. The latch limit can be set to 3. So that a fault can occur if the condition repeats.

Regarding the calibration of the board: The configuration manual has example code to calibrate the board. Taking an example to calibrate current. The steps followed is a 0mA current is applied through sense resistor and the board offset is calculated. Then 1A current is applied through the sense resistor for a duration of 10 seconds where for each second a reading is taken. The average off the readings are stored. This process is repeated for a current of 2A for 10 seconds. Can there be a thingset command similar to yours but for the first 10 seconds its !Cal/xCurrent [0]. The next 10 seconds !Cal/xCurrent [1] and the next 10 seconds !Cal/xCurrent [2]. After the measurement of one current value a message can be printed saying "Calibration for 1A done". So that the user can know when to start the next step.

So, right after the command !Cal/xCurrent [0] is mentioned the board reads the values once per second and takes the sum of all the readings upto that second. After 10 seconds are done for both 1A and 2A the Capacity gain is calculated and stored.

What are your thoughts on the discharge overcurrent and calibration method?