• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 1323 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:

bq34z100 update status to 06 fail

BQ34Z100-G1: Update Status do not change to 0x06

user5014632
Intellectual 515 points
Part Number: BQ34Z100-G1

Hi,

I have conducted a learning cycle on a 12.8V 64Ah Li-ion LiFePO4 battery, however the Update status did not change from 0x05 to 0x06. You can download below a log of the learning cycles (sorry for the size, it is an excel spreadsheet with graphs).

Previous learning on this battery model went fine without that much logging. I wanted to double check the Golden Image generation process but I cannot find out what went wrong for this particular learning. From my understanding of the process, it seems that Ra update did not happen (Update status stuck to 0x05), however RUP_DIS flag has not been set during learning (which mean that initial guess of Qmax was good) and grid number changed normally during the discharges, which should have led to Ra update.

Can you help reviewing this log to find out what prevented the learning to complete?

Best regards,

  • 0
    TI__Mastermind 24870 points
    How did you choose your chemID?

    What C-Rate are you discharging this. Can you attach your gg.csv file?

    It is better that we use the upload button on e2e instead of wetransfer. I don't have access to the files.
  • 0 in reply to Kang Kang
    Intellectual 515 points

    Hi, thank you for your quick answer.

    The Chem ID was selected based on the cell reference from the manufacturer. It already allowed successful learning with this battery.

    The battery is charge and discharge with C/10 rate (10 hours). You will find below the gg.csv file exported after the last failed learning (update status = 0x05):

    20190325_12.8V_64Ah_GI.zip

    The log file is bigger than 20 Mo, you will find it below split in two parts:

    20190325_HET_LiFe_12.8V_64Ah_003_generation_GI_part1.log

    20190325_HET_LiFe_12.8V_64Ah_003_generation_GI_part2.log

    I also have an in depth analysis of the log in an excel file but also too big for sharing, you will find below a selection of graphs from this analysis, I can provide other graphs of the various registers or flags, feel free to ask.

    20190325_HET_LiFe_12.8V_64Ah_003_generation_GI_graphs.docx

    The learning went on for 3 cycles without completing. Battery is a 4S20P with 3.2V 3.2Ah LiFePO4 cells. Important information is that the termination voltage was changed to 2750mV because the protection circuit from the battery did not allow discharge down to the theoretical minimum voltage of 10V (2500 mV per cell). This may be the cause of the failed learning, however I need to confirm it through log analysis since the conditions for Qmax update and Ra update seem to have been met.

    Looking forward to your insights.

    Best regards,

  • 0 in reply to Kang Kang
    Intellectual 515 points
    Hi Kang Kang,
    I have uploaded the gg.csv file and my analysis of the log file.
    Do you have any clue about what happened?
    Thanks for your help.
    Best regards
  • 0 in reply to user5014632
    TI__Mastermind 25955 points

    Hi user5014632,

    Thank you for the logs files - due to current loading these will take time to analyze.  Please expect an update by EOD 4/5.

    Sincerely,

    Bryan Kahler

  • 0 in reply to Bryan Kahler
    Intellectual 515 points

    Hi Bryan,
    Thank you for your answer, and sorry for the funny name, I am logged as Jeremie on my TI account but the system seems to have created an automated profile for the forum and I can't change it.

    I have new information on this issue, I had another failure of learning process with the same symptoms though the terminate voltage was 2500mV and the battery did discharge correctly down to 10V (4 series cells). I can see on both failed gg.csv files that Ra tables have not been updated though the conditions for the update seem to have been met (i.e. Qmax updated and discharge for at least 500 seconds).

    Looking forward to your analysis
    Best regards

  • 0 in reply to user5014632
    TI__Mastermind 24870 points
    If Qmax is updated and Ra tables have not, the first place I would go is the GPC selection. Can you also attach the GPC selection data to this thread?
  • 0 in reply to Kang Kang
    Intellectual 515 points
    Hi Kang Kang, thank you for your answer, unfortunately I do not have GPC selection data, the chemical ID used is 0463, it has been selected based on the cell reference from the manufacturer.

    I also noticed that the failed learning happened with a charging voltage slightly lower than the first successful learning (14.4V instead of 14.6V), though the FC bit was set anyway at the end of charge. Could it be an explanation for the failed learning?
  • 0 in reply to user5014632
    TI__Mastermind 24870 points
    I see, please go through GPC. The chemID is properly selected from the GPC calculator.

    The lower charging voltage to me just indicates more that the chemID needs to go be selected via GPC.
  • 0 in reply to Kang Kang
    Intellectual 515 points

    Hi Kang Kang,

    Thanks to SLUA903 I found out that there is a minimum discharge current limit for the Ra tables to update correctly. I guess I was lucky when I achieved some learning cycles last year, because my discharge current was set precisely on this C/10 limit. I increased my discharge current to C/9 and I also had to tweak a little the end of charge detection (taper current to 150mA and taper voltage to 150mV) and I finally succeeded to get the update status to 0x06.

    20190408_HET_LiFe_12.8V_64Ah_GI_generation.log

    20190408_HET_LiFe_12.8V_64Ah.zip

    However, as you can see in the log, there is no OCVTAKEN during the relax after charge. Actually OCVTAKEN is set when FC is set, but it is cleared as soon as the gauge enters relax mode.

    VOK is not cleared either during the relax after charge. Though it is a step of the procedure described in SLUA903.

    Based on the following thread () I assumed that VOK should clear once the dV/dt criteria is met. This limit is indicated as being 4µV/s in SLUA450 (2.3) and SLUA903. I calculated the dV/dt from the log with a 30 minutes averaging window and it does cross the 4µV/s limit during relax, yet no other OCV is taken and VOK stays set.

    20190416 log analysis.docx

    Could you have a look at the log and tell whether the learning cycle is successful or not?

    Concerning the GPC tool, I submitted several charge discharge profiles of my battery made of 3.2V 3.2Ah cells (chemID 463) but the tool indicates other chemIDs for much bigger cells:

    - 456 (10000mAh cell, max deviation 18.11%)

    - 464 (20000mAh cell, max deviation 20.87%)

    - 457 (70000mAh cell, max deviation 14.85%)

    I think I'm missing something about how to scale the data for submission to the GPC tool.

    Looking forward to your expertise.

    Best regards,

    Jérémie

  • 0 in reply to user5014632
    TI__Mastermind 25955 points
    Hi Jérémie,

    Thank you for all of the details. You're correct, Ensuring that rate is C/10 or above for the learning cycle here is critical.

    Please let me know if the issue persists after the next learning cycle.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Intellectual 515 points
    Hi Bryan,

    Following our call I confirm that the discharge current was the reason for my failed learning cycles. Once I increased the discharge current over C/10 (I set it to C/9), the learning cycle was successful (learned status set to 0x06).

    I can also emphasize the criticity of having the FC bit set at the end of charge, otherwise the learning will fail. In my particular case I had to change the taper current and taper voltages (150 mA and 150 mV) to ensure the gauge as enough time to correctly detect the full charge before the charger cuts-off.

    However, though it is indicated in the learning procedure, the behavior of VOK and OCVTAKEN after charge is less important and the learning will succeed even if VOK is not cleared during relax after charge. I also witnessed OCVTAKEN cycling at the end of charge and never being set again during relax. Yet the learning cycle was successful anyway.

    I lay here the list of SLUAs and datasheet you provided related with the BQ34Z100-G1 so anyone tumbling on the same issue can find all the information on the same place:
    www.ti.com/.../bq34z100-g1
    www.ti.com/.../slua801
    www.ti.com/.../slua792
    www.ti.com/.../slua760
    www.ti.com/.../sluubv2
    www.ti.com/.../sluu904
    www.ti.com/.../slua903

    Basically, the current discharge value and the end of charge detection were the to main issues I had to understand in order to achieve repeatable learning cycles.

    I still have a problem with a kind of overflow on the Available Energy counter, but I will open a new thread specifically for this issue.

    Many thanks for your help.

    Best regards,

    Jérémie