• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 62 subscribers
  • Views 1258 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BQ34Z100-G1: Fuel Gauge Learning capacity of Old Cells

James Coulson
Prodigy 60 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: GPCRA0

Hi,

We are using a BQ34Z100-G1 fuel gauge for a lithium ion battery management system.

We successfully performed a learning cycle on some brand new cells and have been using that golden image successfully for some time now.

In our application we are starting to use second life cells which have been in service in other applications before we use them in our product meaning that their capacity is not what it once was. As we have no control over their previous life, each set of cells will likely be at a different SOH so we would like the BQ chip to re-learn the cell capacity. To do this we have enabled the Impedance Track Algorithm with the IT ENABLE command.

After one full cycle, the SoC appears to track well on a charge (suggesting it has learnt a new capacity) however the SoC on discharge appears to be very inaccurate (it looks as if it thinks its a brand new cell). This appears to be regardless of whether its a full charge or not.

Over a number of cycles it appears to be improving however we would like it to learn as quickly as possible for our end user.

Are there any settings or procedures which will allow the BQ chip to learn the new capacity quicker? or for it to learn discharge as fast as charge?

Thanks,

James

PS. I've attached a graph of our charge discharge cycles. We have plotted the BFG SoC along with a SoC we calculate in the microcontroller Firmware based on a simple coulomb counting algorithm.

  • 0
    TI__Mastermind 25955 points
    Hi James,

    Thank you for the graph. Please run the following steps for your learning cycle. If after the learning cycle, the results are not satisfactory, please use the GPCRA0 tool as well.

    0. Configure dataflash, pack chemistry, perform calibration and export GG File (for later comparison)
    1. Set Update Status to 0x02 then Enable IT
    2. Send Reset command (0x0041)
    3. Charge the pack to charge termination.
    4. Rest until the OCVTAKEN flag sets
    5. C/7 Discharge to the termination voltage
    6. Rest until the OCVTAKEN flag sets. At this point, QMax should update and the Update Status should increment to 0x05
    7. Charge the pack to charge termination
    8. Rest until OCVTAKEN flag sets
    9. C/7 Discharge to the termination voltage
    10. Rest until the OCVTAKEN flag sets. At this point, the Ra table should update and Update Status should increment to 0x06

    Please let me know how it turns out!

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 60 points

    Hi Bryan,

    Thanks for that advice, we performed the cycle that you specified above and removed the learning limits/filters for Qmax and the Ra Table as we hoped this would allow quicker learning. We observed the following:

    - The OCVTAKEN flags were set at the points you said they would

    - The FC flag was never set despite care being taken to ensure the 3 criteria are met (min voltage, max current for 2 taper windows and above min capacity for the same time) and on checking the data after the cycle these criteria were definitely met

    - Qmax and Ra Table appear to have been updated but not to the values we expect, its reporting ~50Ah when we expect ~40Ah

    - Upon checking the data after the cycles we noticed that update status was successfully set to 0x02, however as soon as we started the cycles it jumped to 0x06 suggesting it had learnt its capacity despite being reset.

    - The RUP_DIS flag was set about half way through the second discharge suggesting the RA Table is not being updated.

    I think the following information might be critical:

    - Our cells are nominally 66Ah so we discharged at 10A (~C/7) however the used cells are ~40Ah. Which C rating should the discharge current be based on?

    - The fuel gauge is the same one used in previous tests so could it have remembered previous IT data and set the update status to 0x06? If so how would we go about resetting this? (we reflashed the 'Golden Image' .srec file is this not enough?)

    - The true FCC and RC jump around a bit during our cycling which i've included a graph of. After the first cycle the True FCC appears to be around the value we expect but then jumps back up for some reason once relaxed?

    How would we go about solving these issues?

    Thanks,

    James

  • 0 in reply to James Coulson
    TI__Mastermind 25955 points
    Hi James,

    For the FC bit to set with the current taper charge termination, please ensure that FC Set % = -1.

    To remove the RA table you will need to flash the device with the default SREC, then program in the chemID in the chemistry tab, then load your saved gg.csv parameters.

    The C/7 discharge should be based on the batteries used. The chemID may change between your cells with differing capacities. Please ensure you are using the proper chemID.

    When repeating the above test, please start out with discharged and rested cells.

    If issues still persist after your next attempt, please send me the gg.csv, SREC, and log files from your test for analysis.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 60 points

    Hi Bryan,

    Sorry i forgot to mention we also had FC Set% = -1.

    If we load the default .srec and program the ChemID does that mean we lose all of the data from the learning cycle which was originally carried out? If so would you recommend doing this?

    The ChemID we use is specific to our cells (albeit in a brand new state), therefore if the cells were to age to the same extent (from 60Ah to 40Ah) whilst in our product, does it mean that some way through their life we would need to change the ChemID to maintain accurate SoC?

    Since the above test we have performed another charge/discharge cycle (however this was not logged). I have attached the files you requested above,  taken during the cycle shown in my graph from the last post.

    Do TI offer any kind of paid consultant support? I would really appreciate additional help on this issue as its causing us a lot of grief at the moment and preventing us from releasing a product. We are struggling to point that we may have to design out the TI chip which we would rather not do.

    Thanks,

    James

    CyclingData.zip

  • 0 in reply to James Coulson
    TI__Mastermind 25955 points
    Hi James,

    The default SREC will overwrite everything in the gauge - both instruction and data flash. The data will be lost. To prevent losing this data, save the SREC from the learned gauge and load that SREC on a new gauage.

    You will not need to change the chemID once set. The gauge constantly learns throughout the lifetime of the cell, updating the impedance tables.

    Unfortunately, TI does not offer paid consultant support, but some third party design houses and battery pack manufacturers have quite a bit of experience with these devices.

    Sincerely,
    Bryan Kahler