This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ76952: Cell Balancing draining all the battery cells. What is the ideal way to set it up.

Part Number: BQ76952
Other Parts Discussed in Thread: EV2400, BQSTUDIO

Tool/software:

We have a 13S battery designed using the BQ76952 and are communicating with it over I2C using the EV2400.

Running into an issue with the cell-balancing. Following are the cell-balancing settings in the device memory:

I had increased "Cell Balance Minimum Delta (Charge and Relax) to 250mV (instead of the 40mV default). Not sure if that's the right way to go about it?

I'm attaching below the logs of individual cell-voltages for the cells. You can see how the voltages keep dropping. Draining the battery over time. The PACK voltage went from 52V to 49V.

While draining of the battery at this rate is a major concern.

The other issues is, the BMS doesn't stop draining, it doesn't reach equilibrium. You'll notice in the file below, Cell# 2, has been inherently at a lower voltage (compared to rest of the pack). The BMS allows Cell#2 to drain as well. I was initially assuming the balancing algorithm might allow all the batteries fall down to the voltage of Cell# 2. But if it's allowing even the lowest cell to loose it's energy, it'll drain all the cells and ultimately kill the battery.

02-19-25.xlsx

  • Further to my initial post above. The battery continues to drain.

    It looks like Cell #2 has dropped further than 3300 mV. 

     

    The other question I have is, how does the BMS handle charging of Cell #2 particularly? I was assuming, when I connect a charger, Cell #2 would be the first one to charge and come to equilibrium with others. Followed by the second lowest cell would charge, so on and so forth. But, I'm probably wrong?

  • Hello Mo,

    This previous post explains the specifics of certain cell balancing settings work: cell balancing that may help.

    From the data you shared, there seems to already be a large difference between Cell 16 and Cell 2 (~483mV). With this large of a difference it can be more difficult to balance out, especially if there is a load. The batteries could be discharging faster than it can be balanced out.

    Can you try using the subcommand, CB_ACTIVE_CELLS() and take a log of this to see if it’s actually attempting to balance? Table 10-1. Host-Controlled Cell Balancing Subcommands in the BQ76952 Technical Reference Manual can help with that.

    This previous post cell balancing issues, may also be useful to refer to.

    Best Regards,
    Alexis

  • Hi Alexis,

    Thank you for pointing out the different posts. I have gone through and understood it.

    previous post cell balancing issues

    However, the second post, I'm still grasping.

    In the meantime, updating you on my current status. This morning I found the battery turned off (I believe because it probably triggered the CUV protection for Cell #2, as it was below 2.5V and the overall stack voltage was below 48V). At that point, I charged the battery and gave stricter limits on the cell-balancing. Mainly to avoid cell balancing and see if the battery would still loose power. I'm attaching the logs here for your review. You'll notice the "Cell Balancing Active Cells" and "Cell Balancing Processing Time" is zero. As it doesn't get triggered. But, unfortunately, the battery continues to drain it's power. Not sure why?

    Can you try using the subcommand, CB_ACTIVE_CELLS() and take a log of this

    I couldn't find the "CB_ACTIVE_CELLS()" under the "Commands" section in BQStudio. But upon looking up the Technical Reference Manual, it looked like it was the same as "Cell Balancing Active Cells" register. Please correct me if I'm wrong.

    02-20-25-noCellBalancing.xlsx

  • Hi ,

    This morning, I found the battery continuing to loose power. The Pack voltage dropped from 52.9V to 50.75V. At this rate we'll be draining the battery within 2-3 days. Not sure how to fix this ?

    Cell balancing isn't triggered, because of the strict rules that were placed earlier. I'm attaching the log below for your reference.

    02-20-25-overnight_noCellBalancing.xlsx

  • Hello Mo,

    0x0083 CB_ACTIVE_CELLS()’ is a subcommand. The ‘Commands’ section of bqStudio doesn’t include all the available subcommands and commands the device has.

    it was the same as "Cell Balancing Active Cells" register


    Correct. The “Cell Balancing Active Cells” register, when read, will report which cells are being actively balanced.

    Is the device still on in SLEEP mode or is it SHUTDOWN mode? Also, could you measure the currents on the board? It is unusual to see the battery draining that quickly.

    Best Regards,
    Alexis

  • Hi ,

    Thank you for getting back. Unfortunately, I have another pressing project that has taken precedence over the 13S BMS. I'm hoping to get back to it next week and continue to the testing.

    I don't think the battery is in SLEEP or SHUTDOWN mode. As I had enabled the "ENABLE_ALL_FETs" command. Not sure if it triggers SLEEP mode after that?

    But, I realized, I had the EV2400 and an external power meter connected to the battery in all my tests. I removed both of them, and let the battery sit idle by itself for 3-4 days. I notice it dropped only by 0.02V per 24 hours (compared to the 2V per 24 hours). The EV2400 logging and the power meter were probably the main cause of the battery drain. I believe, with some more tweaking of the registers, the performance can be improved. 

  • Hello Mo,

    Unfortunately, I have another pressing project that has taken precedence over the 13S BMS. I'm hoping to get back to it next week and continue to the testing

    No worries. I hope it all goes well.

    As I had enabled the "ENABLE_ALL_FETs" command. Not sure if it triggers SLEEP mode after that?

    The ‘ENABLE_ALL_FET’s command should not trigger SLEEP mode in itself. SLEEP mode can be entered through a command or if there is low enough current detected if SLEEP mode is enabled. 0x12 Battery Status()[SLEEP_EN] bit indicates whether the device is presently allowed to enter SLEEP mode or not, while the 0x12 Battery Status()[SLEEP] bit indicates whether it is presently in SLEEP mode or not. 

    he EV2400 logging and the power meter were probably the main cause of the battery drain.

    I’m glad you were able to determine that the EV2400 and external power meter seemed to be draining the battery.

    Best Regards,
    Alexis