• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 4 answers
  • Subscribers 66 subscribers
  • Views 1609 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

BQ20Z655-R1: Cell Balancing: Can't get the 655 to execute balancing. Need to learn what knobs we can turn to make this happen...

BQ20Z655-R1: Cell Balancing: Can't get the 655 to execute balancing when expected.

jonathan sarver
Prodigy 40 points
Part Number: BQ20Z655-R1
Other Parts Discussed in Thread: BQEVSW

The FC bit is getting set at the end of charging, and the Ra tables indicate that a Qmax update has completed on each cell.

There are packs that CELL BALANCE intermittently, but those packs do not go into CELL BALANCING all the time.

I have an Excel file that shows BQEVSW log data, including FC & CB bit values over multiple CHG / DSG cycles.

If .gg files are needed for the packs they can be provided.

Thank you,

Jon

  • 0 in reply to jonathan sarver
    Prodigy 175 points
    TI folks: I'm a cohort of Jon and author of the original question of 'What does it take to make the 655 perform balancing.' In addition to packs that balance intermittently, we have packs that NEVER balance. All our packs are 3S1P. The 'never balance' packs have one cell with markedly lower OCV than the other two (which are quite well matched - within a few mV) at any SOC. The low OCV cell can be 100mV below the others at 100%SOC. It almost appears that packs with cells having OCV differences great than "some amount" never balance. Again, our request is understanding "What CAUSES balancing to occur." TI has provided some information that answers questions on "What ENABLES balancing to occur." but we need to know WHAT WE CAN MODIFY to FORCE balancing to occur, not enable balancing to occur. We have packs in desperate need of balancing but can't figure out WHY the 655 will not balance. Thanks, Doug
  • 0 in reply to Doug Jensen
    TI__Mastermind 42535 points
    Doug,

    Cell balancing occurs on the basis of DOD. Our gauges have a voltage delta that once exceeded triggers cell balancing. However, balancing will only be active on a completely learned pack which has DOD values taken. An accurate DOD is essential for cell balancing timers to be calculated. Also, cell balancing is usually only active during charge. In some gauges we have the ability to balance at rest.

    Please send us your gg file in case this explanation is not sufficient and you need us to investigate further.
  • 0 in reply to Doug Jensen
    TI__Expert 6575 points
    Hi Jon and Dough,
    For cell balancing to be actively balancing, the gauge will need to have an accurate capacity measurement i.e. Qmax update.
    When the DOD gets updated at the end of charge, the gauge will also update the cell balancing timers, and during the next charging cycle, the gauge will bypass charge from the cell with the highest capacity until the previously calculated timer for that cell expires.
    When there is another DOD update at he end of charge, the gauge will recalculate the balancing timers.
    From the log file, it does not appear that there is sufficient rest period at the end of charge for the gauge to get a DOD update, and therefore, it may not be updating the cell balancing timers.
    The best option would be to charge to full and let the pack rest till the bit [VOK] in the operation status is cleared. Once it clears the cell balancing timers should be updated, and cell balancing should occur on the subsequent charge cycle.
    Regards,
    Swami
  • 0 in reply to Batt
    Prodigy 40 points

    Yes, we would still like more help with the Cell Balancing issues.

    I am attaching the .gg file from the pack that we have not seen any balancing.

  • 0 in reply to jonathan sarver
    Prodigy 40 points

    I Changed the extension to .xls as it would not alow me to post as .gg2266_9_13_18(1).xls

  • 0 in reply to jonathan sarver
    TI__Mastermind 42535 points
    OK, we'll take a look at it and reply back here.
  • 0 in reply to Batt
    TI__Mastermind 42535 points
    Jon, Doug,

    Your update status for the cell is 0x06. Cell balancing is only activated if the update status goes to 0x0E. Please run another cycle of relax-chg-relax-dsg-relax on a fully discharged battery. Check again at the end of the cycle if update status is 0x0E. After that your balancing will be active.
  • 0 in reply to Swaminathan Ramanathan75031
    Prodigy 175 points

    Swami:  Just clarifying you comment "rest till the bit [VOK] in the operation status is cleared."  I think you meant "rest till the bit [VOK] in the operation status is SET"  Correct?  Packs that complete charging have VOK cleared (a zero in that bit position) at the end of charge, but within about an hour the VOK bit gets SET.  The update status register remains at 0x06 after full charge (with FC bit set).  This charge cycle was done at after a full discharge was performed (resting for at least 18 hours between discharge and charge).  Attached is a gg file captured at this point.  My question is:  I have completed three full discharge cycles (to 0%SOC) followed by full charge cycles.  The last thing done was to fully discharge, wait at least 18 hours and then fully charge to FC bit set, however the Update Status byte remains at 0x06 after the VOK bit was SET to 1.  Why is Update status not changing to 0x0E?  I will be in Dallas for the deep dive next week - and would like to sit down with someone face to face to get a better understanding of this process and what I'm missing.  Thanks!3881_Oct5_2018_shortly_after_FC_charge.zip

  • 0 in reply to Doug Jensen
    TI__Mastermind 42535 points
    No, Doug. He actually means wait until VOK is reset or cleared (set to 0). This is because the clearing of VOK indicates that you have taken an OCV that is qualified for an update. If VOK gets set after chg following a reset, that means that there was a start of dsg detected. Otherwise it would never set. Once resistance and Qmax have been learned following the 1st chg dsg you can expect update status to be set to 06. The successive chg would not change update status to 0E. It's the relaxation after dsg during the second cycle following chg relaxation that will qualify for it to get there.