• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 3 answers
  • Subscribers 62 subscribers
  • Views 722 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.

BQ34110: false SoC values when charging starts above 35°C

ken thompson
Intellectual 630 points
Part Number: BQ34110
Other Parts Discussed in Thread: GPCCEDV, BQSTUDIO

Tool/software:

We have discovered that gauging that works normally at room temperature fails when the gauge sees temperatures above 35°C at the beginning of a charge. When temperature is thus slightly elevated, this gauge tracks charging seemingly OK for only a minute and then, in a step function, reports falsely a 100% State of Charge and the Full Charge Capacity as the Remaining Capacity. Attached our log file over a number of days.nmh-10 7.18.24 pm.csv Controlled temperatures were accomplished by providing a gentle fan to the pack. To raise the temperature and simulate installation in our application, 3/4" of foam was placed around the pack. This did cause the charging to hiccup, but the concern here is the gauge behavior in the first couple of minutes of charging while warm: The false indication from the gauge of a full charge accomplished.

The pack is  5 cells of  NiMH .

  • 0
    TI__Mastermind 28785 points

    Hi,

    Have you used the GPCCEDV tool?

    Can you share your .gg file?

    Regards,

    Evan

  • 0 in reply to Diego
    Intellectual 630 points

    Using bqStudio to monitor the gauge. Do not know GPCCEDV.NiMH_master_parameters.gg.csv attached is the file loaded into every unit. the only calibration being done is the pack voltage.

  • 0 in reply to ken thompson
    TI__Mastermind 28785 points

    Hi,

    Please calibrate voltage and current, using a power supply.

    please use this tool: GPCCEDV Application software & framework | TI.com

    Thanks,

    Evan

  • 0 in reply to Diego
    Intellectual 630 points

    We have been using bqStudio, this file, and the process for 9 years, and are trying to figure out what has changed recently that is causing us a number of issues with our finished product. We found this jump-in-reported-SoC-when-warm issue and wanted to find a resolution to this very repeatable and problematic behavior believed to be separate from any coulomb counting gauging issue.

    We do not have simple access to doing a current calibration because the product has an integrated charger, the gauge on the cells, and a following boost regulator that ends up providing a constant power load. The charging current from the charger is well represented by the gauge's reading of that parameter, and presenting little concern to the issue at hand.

  • 0 in reply to ken thompson
    TI__Mastermind 28785 points

    Hi,

    To confirm, this configuration in has been used in the field for 9 years with no issues, this is the first time an SOC jump has been seen with this configuration?

    Were the field conditions for this gauge the same as the rest of the gauges?

    The gauge should have been calibrated prior to deploying into the field.

    If the error only happens at high temperature, there may be an error with your CEDV profile, the high temp discharge using the GPCCEDV tool should correct this.

    Regards,

    Evan 

  • 0 in reply to Diego
    Intellectual 630 points

    This has only recently been noticed. It may be happening with older units. That is another investigation path we are working.

    We see this behavior only when the temperature at the beginning of charging is about 35°C or anywhere higher than that.

    The gauge is always calibrated before leaving our facility.

    We sent you the .gg file for review. Our cells are Panasonic AA NiMH. We also sent you a log file showing the spikes up in RSoC only happening when there is an elevated starting temperature. Plot time, current, temperature and RSoC and you will see the RSoC ramping up when starting at room temperature and spiking up when starting charge at above 35-37°C.

    It is hoped TI would consider attempting duplication of this in their labs with our .gg file and work toward a solution, either with our file or fixing the firmware in the gauge. We can only report the gauge behavior and cannot fix it ourselves.

  • 0 in reply to ken thompson
    TI__Mastermind 28785 points

    Hi,

    We currently do not have the resources to recreate this in our lab, I have suggested how you can correct this error.

    Regards,

    Evan 

  • 0 in reply to Diego
    TI__Mastermind 28785 points

    If you have further questions regarding running the GPCCEDV tool feel free too ask.

    Thanks,

    Evan

  • 0 in reply to Diego
    Intellectual 630 points

    Looking at the tool, it appears to want six continuous discharges at three different temperatures, to characterize the cells in use during discharge. We think this was done for our initial production and reflected in the .gg. file we sent. Has this file been reviewed? Did it indicate an issue in our configuration?  We can repeat this and it will take a few days to complete, however:

    Our present issue though is not with indications during discharge, but with the gauge's indications a minute into charging and only while slightly warm.

    This would appear to be unrelated to any data matrix logged during discharges for the GPC CEDV tool.

  • 0 in reply to ken thompson
    TI__Mastermind 28785 points

    Hi,

    If the tool was used originally used on the .gg there could have been a mistake made with the high temp chg/dschg. 

    Yes, but SOC jump only occurs at high temperature, this leads me to believe there is an error in your CEDV configuration. Adjusting this may not fix the issue but it is the most logical place to start.

    Please share the GPCCEDV data and report once available.

    Regards,

    Evan

  • 0 in reply to Diego
    Intellectual 630 points

    Does our .gg. indicate a mistake? 

    You write of a possible mistake in "the high temp chg/dschg." The GPC CEDV test logs appear to have only discharge recordings specified. Charging is not part of the data requested for the tool.    What are we unclear in our understanding of this?

  • 0 in reply to ken thompson
    TI__Mastermind 28785 points

    Hi Ken,

    I do not inherently know if there is a mistake made simply by looking at the .gg file.

    If you suspect that your cedv profile is correct, then I suggest looking into verifying all the charging parameters are correct. Chapter 2.9 in the TRM.

    I also have a question when FC is detected and Remcap jumps to FCC=Remcap, is the battery fully charged at this point or is the battery only particially charged when SOC = 100%

    Regards,

    Evan

  • 0 in reply to Diego
    Intellectual 630 points

    FC is reported and no the pack is not fully charged (0.5 C charging has only been for about one minute from empty) when SOC is reported to be 100%.  A discharge at this point shows the cells fully deplete in a very short time.

    Chapter 2.9 appears to be covering the set of parameters used to allow the gauge to control a TI charging scheme/IC. We are not using that feature of the gauge. We are using a charging circuit designed specifically for NiMH cells that includes both temperature and voltage peak termination capabilities and is totally separate from the gauge, so the mentioned chapter is thought to be not applicable.

  • 0 in reply to ken thompson
    TI__Mastermind 28785 points

    Hi,

    What about these parameters.

    Regards,

    Evan

  • 0 in reply to Diego
    Intellectual 630 points

    So this turned out to be an issue. The default for NiMH_CHG_EN is zero. Sometime in our cell qualification in the past this was set on. It is supposed the gauge then thinks it is in charge of charging through an SMB/I2C interface ?  But it does seem to think also that any temperature rise when already above 35°C is cause to mark the cells 100% charged, even when only one minute of coulombs have been metered into the cells. So there is still a serious issue with the gauge's actions, but making sure NIMH_CHG_EN is off fixes this for us since ours is an independent charger.

  • +1 in reply to ken thompson
    Intellectual 630 points

    Turning off the nimh_chg_en is a problem too, because the gauge then cannot detect end of any charge and cannot update its SoC % reliably. We had to switch to Nidv and use the NiMH voltage rise to allow the gauge to detect end of charging. We feel the issue with a normal, beginning of charge, temperature rise causing the gauge to wrongly report 100% SoC at the beginning of charging is still a gauge flaw, but we have this workaround for our application.