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: BQ76952 top-cell balancing current less than other cells

Part Number: BQ76952

Hi,


i have a 10s design with cell 1 on 0-1 and cell 10 on 15-16 with 10,11,12,13,14,15 bridged.

I have set the slow loop to 1,1 which is 1/8th speed.


Autonomous balancing seems to always restrict top cell balancing current (both observed and reported through the balance seconds per-cell query) to less than half of other cells.

Do we know what might cause top cell to get lower balancing time than other cells?

  • Hi Richard,

    Are you using external balancing FETs or internal balancing only? What is the value of your cell input resistors?

    The VC16 input does supply current to the internal cell balancing FETs so there can be some IR drop across the VC16 resistors. This is described in a little more detail in section 2.5 of the Cell Balancing with BQ769x2 app note: https://www.ti.com/lit/an/sluaa81/sluaa81.pdf

    This IR drop affects the voltage observed at VC16 which may be causing the device to balance the top cell for less time. If you are using 100 ohm resistors for all of the cell input resistors, a common solution is to reduce only the VC16 resistor to 20 ohms to reduce this effect. Do you think this may describe what you are observing?

    Best regards,

    Matt

  • I'm using 20 ohm resistors and 0.22uf caps.

    I see something unexplainable on the top 2 cells: cell 10-of-10 between vc15-vc16 and the next cell (cell 9-of-10) between vc8-vc9.

    Unlike the other lower cells which see a balancing pattern which is ON with a 90% duty cycle (off 10% every 1s), the top 2 cells have a 50% duty cycle when balancing.

    See below for the voltages at each side of the balance resistor on cell 9-of-10/vc9. The swing above cell is the pullup from balancing top cell, and the pull below is the balancing of 2nd top cell. Both see this 50% pattern.

    Do you know why this could be?

    And for reference the lower 8 cells

  • This is a zoom on horizontal of top cells

  • Hi Richard, 

    The schematic looks okay, but there is one resistor in the top right corner (R48?, I cannot read it very well) that connects to the top of Cell11 - I'm not sure I understand the reason for this component.

    When you are seeing this behavior, can you read from the Safety Alert registers to see if there is any type of protection condition that may disable balancing on cells? Also, can you describe how you are forcing an imbalance - are you using real cells? Can you share the device register settings?

    Thanks,

    Matt

  • Yes -- the Cell 11 resistor is a 0 ohm optional to bridge -- it's not installed and not used (now that I understand that the top cell must always be used for lower cell counts). Top cell is now on 15/16.


    There are no safety alerts and balancing seems to always run.

    I did find one thing: i had transposed the slow loop/cb slow loop; i've corrected that now and see a 90% duty cycle on the top 2 cells.

    However, it stilll seems that the cumulative time problem exists -- the highest cells still get 50% balancing time of the others. Also Cells 7,9 get exactly the same balance as each other, as do 6,8. 

    q1: why would both Cell8  (of 0->9, vc7-8) and cell 9 ((9 of 9, vc15,16) be affected with the 50% duty cycle when CBSLOW is 0,0? The docs only say top-cell.

    q2: why would the top two highest voltage cells only get 50% of the reported balance  time with CBSLOW 1,1?

    See below for the past 24 hours where the top cell voltage by var is still cell8(of 0->9) and cell9 (9 of 9).

  • q3: why would the top 2 cells which have such different balance time report voltages for weeks that are with 1mv of each other?

    It seems empirically that both top two installed cells are getting exactly the same amount of balancing, which is different to what is reported in the balance counts?

  • > Also, can you describe how you are forcing an imbalance - are you using real cells?

    Yes this is a real pack which drifted - I believe originally because I was not using the top cell vc15/16 which is an unsupported configuration.

  • Hi Richard,

    I'm re-reading through the descriptions and images and I am not sure I have a clear understanding. 

    • From the 1st image in the original post, it shows that the top cell has the highest voltage. This should mean it needs to balance for the longest amount of time, right?
    • Are you using the autonomous cell balancing feature of the BQ76952? If so, what are your settings (number of cells allowed to balance, balancing during relax or only during charge, start/stop voltages)?
    • It sounds like you have resolved the issue with the duty cycle (fixed the CB_SLOW setting to 0x11), right?

    Regards,

    Matt

    • From the 1st image in the original post, it shows that the top cell has the highest voltage. This should mean it needs to balance for the longest amount of time, right?

    Yes -- that's what I'm expecting to see, but it not reported to be happening by reading the cumulative balance time registers.

    • Are you using the autonomous cell balancing feature of the BQ76952? If so, what are your settings (number of cells allowed to balance, balancing during relax or only during charge, start/stop voltages)?

    Yes -- this is all fully autonomous mode only.

    I've tried this with multiple configs one week at a time; limit to 4 cells, or set all cells (obviously those allowed in vcellmode bitmap).

    • It sounds like you have resolved the issue with the duty cycle (fixed the CB_SLOW setting to 0x11), right?

    Yes -- so now top two cells (vc15,16 vc,9) are seeing the 90% duty cycle instead of both getting 50% before. the 2nd top cell behavior is still unexplained and is not what the documentation says would happen (docs say  top cell only).

    baja24.gg.csv

  • btw you may notice the min mv for balancing is quite higher than the default of 20mv -- i increased this in the past week to prove/disprove the top.2 cell behavior.

  • Hi Richard,

    Can you point me to where you are seeing the top cell only description in the documentation?

    The best way to debug exactly what is happening is to log the behavior over time - it is good to log all of the cell voltages, the Alarm Status and Safety Status registers, and the Cell Balancing Active Cells register. This way we can see which cells the device is selecting to balance and what the measured cell voltage is at that time. It would help to determine if cell voltages are reading accurately or if any of the protections are interfering. 

    Matt

  • ok i will log those and report back.

    I see the text in (your doc!) SLUAA81  "Balancing is temporarily disabled during the regular measurement loop while the actively balanced
    cell is being measured by the ADC, as well as when the cells immediately adjacent to the active cell are being
    measured. Similarly, balancing on the top cell is disabled while the stack voltage measurement is underway. This
    occurs on every measurement loop, and so can result in significant reduction in the average balancing current
    that flows."

  • Here is another update of the cell balance count registers -- when top 2 cells (8,9) are 160mv higher than the lowest. It seems that it's prioritizing, but now even after cbslow 1,1 cell 8 is getting 50% more balancing than 7,8

  • I don't know if I can explain the time differences fully, but a couple of other things to consider:

    - The algorithm cannot balance adjacent cells at the same time. So it is likely balancing cells 7 and 9 at the same time and cell 8 at other times. 

    - The internal balance resistance of the top cell is lower (see Figure 7-18 in the datasheet), so the cell should discharge a little faster. Additionally the IR drop across the 20 ohm input resistor (35uA * 20Ohms * number of cell balancing) will result in the BQ76952 measuring this cell as a few mV lower when any cells are balancing.

    Matt