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.

BQ76942: Cell balancing not bringing cells to equilibrium state

Part Number: BQ76942
Other Parts Discussed in Thread: BQ76930, , BQSTUDIO

Hello,

We're using the auto cell balancing feature that's provided by the protection IC, and are experimenting with the feature to see how well it can balance a battery. We have a 10-cell LiPo battery, where each cell can be safely charged to a maximum of 4.2V (42V battery).

Our experiment starts with choosing a random cell on the battery, then shorting that cell to manually imbalance it. We chose a relatively safe delta of 20-26mV so that it should be relatively easy to recover. Next the auto cell balancing algorithm is enabled with the following config.

  • 1 cell allowed to short
  • Relaxed min delta of 13mV
  • Relaxed stop delta of 10mV

After about 24 hours of balancing the the max delta hasn't really changed that much, with the max delta sitting at 21mV (as opposed to 26mV). Could we be provided some insight into what the limitations, expectations, and possible issues of cell balancing could be?

I've provided two images to parts of our schematic that depicts the individual cell balancing FET circuit, as well as the whole balance circuit in relation to the protection IC. Please analyze them and let us know if there are any glaring issues with them, but for the most part they were taken from the reference design provided for this chip.

FET circuit

Balancing Circuit

  • Hi Alexander,

    I am a little confused by your description and images. The thread title and description sounds like you are using the BQ76942, but the images show a schematic using the BQ76930 which is a different device that does not have autonomous cell balancing.

    Can you please help clarify?

    Thanks,

    Matt

  • Hi Matt,

    That must just be mislabeling in the schematic, we are most certainly using the 76942

  • Hi Alexander,

    It is not simply mislabeled. The image clearly shows the BQ76930 with the pin names, components, and connections for that device. Maybe you shared the wrong images?

  • Hi Matt,

    You're absolutely right, good catch!

    Here is the current revision.

  • That makes more sense. The schematic looks good to me. So you are discharging one of the 10 cells by 26 mV and after 24 hours, the other 9 cells have adjusted by ~9 mV? What is the capacity of the cells?  

    Also, can you verify that the balancing is occurring by reading from 0x0083 Cell Balancing Active Cells?

  • Each cell is rated at 3300mAh

    Cell balancing is confirmed both via the register, and by probing R15 to make sure current is flowing.

    Here is the discharge curve per cell

  • Hi Alex,

    Doing some quick math based on this curve, I would expect you would need to discharge each of the other 9 cells by ~100 mAh to change the voltage by around 26 mV. So even if only one cell is balancing at a time, it seems like 24 hours should be enough time to bring down the other cells to the stop delta voltage based on your cell balancing current. So I'm not sure why it didn't complete. 

    Do you think you could repeat the experiment while logging from BQStudio so we can see the behavior over the time period?

    Best regards,

    Matt

  • I cannot log from BQStuido since it is our custom solution.

    Just to be clear, I'm using the auto-balance feature with a one cell balance configuration, and am not using the host control commands in an attempt to balance.

  • Understood. Do you have any way to log the cell voltages and Cell Balancing Active Cells register? 

  • I do have a CAN port I can shovel some data out of... I'm not sure how useful it will be though. From what I can tell the balancing algo with a 1-cell config will scan across every cell and balance them for an equivalent period of time.

  • Hi Alex,

    That is correct, it will balance only one cell at a time according to your settings. 

    Matt

  • Hi Matt,

    I was more so inquiring about the algorithm itself. A scan seems like it would be the least optimal solution for balancing

  • Hi Alex,

    I'm not sure I understand what you mean. I do not have all of the details on the algorithm, but I believe it will balance the highest cell if you restrict it to balance only one cell at a time. Another thing I forgot to ask - what are your settings for the CB_SLEEP and CB_NOSLEEP bits? See Table 10-3 in the TRM which describes the valid settings for these bits and the resulting behavior.

    Matt

  • We're not seeing the highest cells being exclusively balanced, which is what I was pointing out, it instead scans across all the cells and balances them equally.

    We have CB_SLEEP set to 1 and CB_NOSLEEP set to 0

  • Hi Alex,

    I think the only way we can effectively see the reason for the balancing time is to log the behavior. 

  • Hi Matt,

    I agree, I'm working on getting that data exposed over CAN

  • Hi Matt,

    I have a plethora of data available for you! Attached is a CSV that contains the cell voltages and the selected cell to balance. The first column is the 16-bit cell balance register, and the next 10 are cells 1-10 in order. Each row represents a 5 second interval (~18 hours worth of data).

    What I did for this experiment was first purposely imbalance one of the cells (cell 10) over 30mV from the lowest cell. During data capture I applied a low current charge of 1A to the battery, and started the autonomous charging with a 1 cell config. I chose 1A as the charge current so that the balancing circuit discharge current would exceed the amount of current charged per cell (100mA/Cell = 1A/10Cells).

    It seems that given enough time the battery does become more balanced, but has a difficult time converging past ~15mV min/max delta.

    I've also attached some images for portions of visualized data. There are some interesting events in the data that I'd like you to look at, for example the max-min delta increases every time the first cell is shorted.

    Could you describe what is and is not expected behavior based off of the plots? I've attached a public google drive folder that has the raw data, as well as images of some plotted data (delta of voltage, and cell chosen for balancing).

    The large data set is titled bms_balance.csv

    bms_balance_2.csv contains the cell and balancing data when in a "steady state", this was captured after the 18 hour cell balancing.

    bms_no_balance.csv contains the cell voltages after balancing was manually disabled.

    The images are 2-Y-Axis plots that contain the Max-Min cell voltage delta as well as the chosen cells for balancing in the auto balance feature.

    Balancing cell data

    Cheers,

    -Alex

  • Hi Alex,

    Unfortunately, I cannot access a public shared drive from our network. Are you able to upload these on E2E? 

    You mention that the device has a difficult time converging past ~15mV min/max delta? What are your configuration settings for Charge min delta and Charge stop delta?

    I am not sure I follow the calculation for the charge current per cell. Your cells are 3300 mAh, so when they are in series the same current flows through all of the cells. The capacity does not increase, only the voltage. Unless you have cells in parallel? 

    One thing I forgot to mention earlier when looking at your schematic. I am not sure if your data shows this, but the voltage measured on the top cell (at VC10) will be slightly lower during balancing because there is some IR drop across the cell input resistor. Decreasing the value of R4 to 20 ohms helps this. The amount of current flowing through R4 is proportional to the number of cells balancing simultaneously. One other potential improvement - reducing the cell input capacitors to 0.22 uF reduces the RC time constant. This may not be an issue you are seeing, but a large RC time means longer settling time which could slightly affect the voltage measurement accuracy during balancing.

    Best regards,

    Matt

  • Thanks for the insight Matt.

    Could you post a link to where I can link my data? There doesn't seem to be an option in the thread.

  • Can you click the Insert => Image/video/file button to see if it let's you upload the files?

  • Hi Alex,

    Can you please describe what you are showing in these files and in the images? 

  • Hi Matt,

    I will try to respond on behalf of Alex. For the CSV files, I'm told the first column has the bit vector representing which cells are being shorted. The remaining 10 columns represent the cell voltages at a given time stamp. The data is sampled at 5 second intervals.

    He also has this above regarding which csv file captures what and what he has in the plots.

    The large data set is titled bms_balance.csv

    bms_balance_2.csv contains the cell and balancing data when in a "steady state", this was captured after the 18 hour cell balancing.

    bms_no_balance.csv contains the cell voltages after balancing was manually disabled.

    The images are 2-Y-Axis plots that contain the Max-Min cell voltage delta as well as the chosen cells for balancing in the auto balance feature.

    For each plot, red represents the difference between the max and the min cell voltages and blue shows which cell/cells being shorted (as far as I can tell.)

    Also I took a note on your comments on R4 and C16 (per cell). In the next iteration, we are moving D5 (a TVS diode) to between C_UP and C_DOWN and place a 5.6V Zener diode in its current location.

  • I'm adding two more data sets that contain a much more extreme case for balancing. The starting voltage for the lowest cell was 2.8V, while the nominal cell voltage was ~3.4V. CSV's contain headers this time Slight smile

    This file contains the balancing run with 1 cell config when the 1st cell was most imbalanced.

    bms_imbalance_balance.csv

    This file contains the balance run after it mostly stabilized. Balancing converges to about a 120mV delta, and cannot surpass it.

    bms_balance_later.csv

    Do you believe that shorting more cells during balancing would help converge past the 120mV?

  • Hi Alex,

    It seems strange that Cell 9 was initially unbalanced but later Cell 7 is unbalanced while Cell 9 matches all of the others cells. Do you have any insight to what happened? At the end of the first file, Cell 7 is still looking good and then it is way off at the beginning of the 2nd file.

    Matt

  • Hey Matt,

    Sorry, I missed cleaning up some of the data, I wrote a quick script to parse the CAN logs.

    Here's the data cleaned up (same file names)

    3247.bms_imbalance_balance.csv

    8228.bms_balance_later.csv

  • Thanks Alex. This is clear. Can you let me know all of the parameter settings below?

  • Hi Matt, I will have one of our colleagues get this info to you. In the meantime, I'm reading through the information Alex provided and noticing that he forgot to mention that our battery pack is actually a 10S10P pack configuration consisting of a total of 100 Sanyo/Panasonic NCR18650GA cells. So every cell group is actually rated at 33Ah, not 3.3Ah.

    With this in mind, could you tell me again what values you would recommend for R4 and C16 (per cell)? Also, I'm curious if this bit of information will make some of the discrepancies in logged data make more sense.

  • Hi Deniz,

    That's good to know. The only real difference though should be the balancing time. No component values should need to change. A smaller R4 (VC16 only) is sometimes used because there is some IR drop on the top cell measurement during balancing (35uA * R4 * number of cells balancing). Since you are only balancing one cell at a time, this is very small. Some users use 20 ohms for this resistor only while keeping all others at 100 ohms. However, this is not related to the behavior observed in the log files.

    The behavior we want to debug is why balancing is stopping. This may be related to the parameter settings which set when to balance and when to stop.

    Best regards,

    Matt 

  • Hi Matt,

    Here are our cell balancing config parameter settings.

    Balancing Configuration 0b00000111
    Min Cell Temp -20
    Max Cell Temp 60
    Max Internal Temp 70
    Cell Balance Interval 20
    Cell Balance Max Cells 1
    Cell Balance Min Cell V (Charge) 3900
    Cell Balance Min Cell Delta (Charge) 40
    Cell Balance Min Stop Delta (Charge) 20
    Cell Balance Min Cell V (Relax) 2900
    Cell Balance Min Cell Delta (Relax) 13
    Cell Balance Min Stop Delta (Relax) 10

    The balancing configuration was set to allow balancing during charging, relax, and sleep. Temperature settings were left untouched, as were the balance interval, number of cells to balance, and Voltage Threshold/Delta for Charging. For a relaxed state, which we are currently attempting to balance in, we set the minimum cell voltage to 2900 (which the data comes slightly close to at 2995 mv lowest), and the min cell delta to 13 mv and the stop delta to 10 mv. We also raised the discharge current threshold, as well as the charge current threshold to -30000 and 30000 respectively to ensure that we are always in a relaxed state.

    Thanks,

    Ryan 

  • Hi Ryan,

    One other thing to check is the Safety Alert and Safety Status registers. An alarm could stop the balancing temporarily. What is the COV threshold set to? When your cell voltages get to 4.2V is the charger disconnected?

    Matt

  • Hi Matt,

    The COV Threshold is set to 4.2V. The CUV threshold is set to 2.3V. When the cell voltages get to 4.2, yes charge is disconnected.

    Thanks,

    Ryan

  • Hi Ryan,

    In this case, it might be possible that the COV Alert is being triggered which would stop balancing. In the log file, the other cells are right at 4.2V so if you are trying to charge the lowest cell, the other 9 cells will trigger the COV Alert. It would be good to monitor the Safety Alert registers to confirm this is the case.

    Matt

  • Matt, I have another question in this regard. I see that you brought up how 1uF caps on the cell input lines might be an issue. I also see that the caps used on both the eval board and the reference design are 0.22uF. I can switch to this in the next iteration but I want to do some more immediate testing to see if this is part of the problem. Can I use 0.1uF instead since I have this in house? Alternatively I could stack up two 0.1uFs to get as close as I can to 0.22uF. What do you think would be better? 0.1uF would be the most convenient option since we already have 0.1uF 100V X7R 0603 caps on our BOM.

  • Hi Deniz,

    0.1uF caps will work. On the EVM we use 0.22uF but have 20 ohm cell input resistors. Since you have 100 ohm cell input resistors, you still have a good time constant which is helpful with large transients during short circuit testing.

    However, I do not think the capacitors explain the behavior observed in the log files. If you were seeing lots of measurement variation, then decreasing the cap size could help, but I think it appeared to be stable. The issue I saw in the log files was that the cell balancing was stopping. That is why I was suggesting to log the Safety Alert registers to see if there is a COV Alert causing this.

    Best regards,

    Matt

  • Hi Matt, we have a new iteration of the board with 0.1uF caps per cell and 33R instead of 100R for R4 on the schematics above (the resistor connected to the higher side of Cell 10). When we start charging the voltages we read on cell 1 and cell 10 become much higher so we prematurely end charging since over-voltage protection is triggered. I'm guessing we need to change our sampling settings. Is there anything you recommend on top of your head we should be looking into as we try to configure things?

  • Hi Matt, you can ignore this. It seems to have been bad hardware. We switched to another board and it now works as expected.