• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 2620 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: Problems configuring device to measure SOC and Remaining Capacity

Kyle Trenholm89
Intellectual 285 points
Part Number: BQ34110
Other Parts Discussed in Thread: BQSTUDIO, , EV2400, GPCCEDV

I'm working with a BQ34110 to monitor a 3000mAh 25.4v LiFePO4 battery pack.  The pack contains 16 cells total.  They are configured as 8 series sets of 2 parallel cells, so as far as the gauge is concerned, I am using 8 series cells.  I am using bqStudio w/ a EV2400 to communicate.

The problem I'm having is configuring the gauge to correctly monitor the remaining capacity and Relative State of Charge.  I have set up the Voltage Divider parameter, calibrated the voltage and current, set the number of series cells, and I am getting accurate readings for both Current and Voltage from the battery pack.  After draining the battery pack, I then charge the pack using a supplied charger (We will not be using the charging functionality of the bq34110).  The bq34110 appears to properly measure charging current and increases the Remaining Capacity up to the 3000mAh.  I then began to discharge, and to my surprise, the remaining capacity suddenly shoots down to <10% and the Full Charge Capacity register now reads 2744mAh.  This is odd, as I had thought this register could not change unless a "Qualified" discharge was detected, and the VDQ bit that detects this state never went high during the discharge.

So at the moment I'm not quite sure what to do from here.  Have I missed a step in the process of configuring the bq34100?  Is configuring the CEDV profile mandatory to use the device in this way?  If that's the case, is there an up to date reference on how to acquire these parameters and take these required logs? Are all six different logs required? (also FYI, the CEDV Technical Reference link in the GPCPackager tab is dead) What portions of the device do I actually need to configure to simply have access to Current, Voltage, and Remaining Capacity?

Thanks in advance for any assistance

  • 0
    TI__Mastermind 25955 points
    Hi Kyle,

    To have the gauge 'gauge' properly, the CEDV profile must be set. Please create the 6 logs required by the GPCCEDV tool to get those coefficients.

    For more information on the tests required for the GPCCEDV tool ( http://www.ti.com/tool/gpccedv ), please read the user's guide found at: www.ti.com/.../sluub45

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

    Thanks for the reply, for these logs, I will have to perform a manual run of the GPC Cycle in bqStudio as I do not have a way to automate the process.
    However the first step of this process appears to be charging the battery to full in order to set the FC bit. I have charged the battery, but this bit does not set. I had thought these FC/TC/FD/TD voltage thresholds were set by the CEDV profile?

    Also, I am seeing that each time I discharge the battery my FCC value is decreasing by about 200mAh and FCCX is toggling. I thought this value could not update unless a qualified discharge occurs? VDQ has never set, so how is this value changing?

    Thanks again
  • 0 in reply to Bryan Kahler
    Intellectual 285 points

    Update to provide more information on what I've tried.

    I'm attempting to coax the bq34110 to set the FC bit to begin logging a GPC cycle as specified by bqStudio.
    With the charger connected, my voltage when max charge is indicated by the charger is 29V. Assuming the FC voltage threshold register is looking for a single cell voltage, I divide this by 8 cells to arrive at a value of 3625mV. I saved this to DF, reset the device, and performed a charge to full capacity, but FC is not setting when I cross the 29V threshold on charge. I have also attempted to set reasonable Fixed EDV0/1/2 values in DF based on information in the TRM as well as logs of previous discharges that I have taken.

    There's got to be something I'm missing but I'm not sure what. Can I run a GPC Cycle anyway and log the discharge and not concern myself with the FC bit? The status in the Control tab remains on "Start task: Charge ( FC Bit = true )", but doesn't seem to have any effect the actual logging process. Should I just log a complete discharge anyway regardless of the status reported by the GPC cycle? The sluub45b guide does not specify any sort of rest period before or after the discharge, so I assume they are not required? I am running the cycle manually, as I do not have the device configured for automatic control.  If possible I'd like to know if I'm doing this all right before utilizing a thermal chamber to make the required logs.  Would hate to take all that time to only realize at the end that the data is no good!

  • 0 in reply to Bryan Kahler
    Intellectual 285 points

    Bryan,

    I have taken what I believe to be a valid log for discharge at Room Temperature - High Rate.  Of course, since I can't get FC to set, I do not have an indication as to if the log was taken properly.  Would you possibly be able to tell us if this attached log is OK for what GPCCEDV is looking for?  I have the plotted data of voltage and current below, but I can't seem to attach my CSV? Sorted it out, needed to be a .log file.

    4024.roomtemp_highrate.log

    Thanks in advance

  • 0 in reply to Kyle Trenholm89
    Intellectual 285 points

    A bump and an update.

    Still unable to get FC to set, which is still hanging the GPC Cycle "Process" at "Charge".  FC Set Voltage Threshold is set to 3625mV.  29V is what I'm reading off the charger when it completes charging, for a single cell, that would be 3625mV.  The gauge is properly gauging the voltage and is recognizing the battery as fully charged at 100%, but FC does not set.  What do I need to do to have FC set at a full charge?  Again, I am not using the bq34110 for charging functionality, only for gauging and monitoring.  We are using a separate circuit to handle all charging.  I'm thinking I perhaps have to modify the DF values for charger control.  We do not plan on modifying the charging current/voltage based on temperature.  Does this mean I can just set the Charge Voltage/Current Tx-Tx+1 data flash values to a set of identical values?  What about the "Charge Voltage Level A-H" values?

    Still looking for clarification of what exact run of data the GPCCEDV Tool is looking for as well.  The bqStudio v1.3.80 interface for a GPC Cycle infers that I need a full charge/discharge with a "Relax" period (of unspecified length) in between.  SLUUB45B, the User's Guide for CEDV data collection I was referred to makes no mention of taking data during charge, or a relax period, it only mentions taking data from discharge cycles.  

  • 0 in reply to Bryan Kahler
    Intellectual 285 points

    Bumping up again.

    Still waiting on any kind of confirmation on what I need for GPCCEDV.
    - sluub45b only notes needing data from a discharge cycle.
    - GPC Cycle in bqstudio seems to want a full charge/relax/discharge cycle.

    What am I following here? Is the data I posted above what GPCCEDV is looking for? Or do I need to re-run with a full charge/relax/discharge?
    Also, FYI, the link to download the manual on the GPCCEDV page (www.ti.com/.../GPCCEDV) is dead.

    EDIT:

    Okay I think I've got a handle on what bqStudio actually wants, a confirmation would be lovely if possible:

    1) Begin process at room temperature.

    2) Begin GPC Logging for desired rate/temp.

    3) Connect Charger (any rest period needed before connecting?)

    4) Wait for full charge [FC == 1]

    5) Disconnect Charger.

    6) Set temperature chamber to desired temperature.

    7) Wait for battery/components to get to temperature.

    8) Wait for relax state [RELAX == 1] if not already in relax state.

    9) Connect load for desired current draw.

    10) Wait for full discharge.

    11) Stop logging. (does there need to be a rest period after discharge?)

  • 0 in reply to Kyle Trenholm89
    TI__Mastermind 42535 points

    Kyle,

    You don't need a relax period for a cedv run.

    For using GPCCEDV please run 2 sets of dsgs at 3 temps.

    The lower rate of dsg should preferably be about half the high rate of dsg. The high rate should be slightly higher than the nominally expected rate of dsg.

    The temps should be 0, 25 and 50C preferably. Or, if you know the exact operating conditions you can fill in that temperature in the mid range.

    Trim the logs as explained in the app note and then upload them to the gpccedv tool to get your cedv coefficients.

  • 0 in reply to Batt
    Intellectual 285 points
    Batt, thanks for a reply, I was starting to think I wasn't going to get anything more in response.

    "Trim the logs as explained in the app note"
    - What app note are you referring to here? Because I have found no references on how to trim the logs properly in any documentation I have read.

    Furthermore, SLUUB45B mentions a configuration file. Most of the values are self explanatory, but could you explain the following?

    FitMaxSOC = <Integer ranging from 8 to 14. Typical is 12>

    FitMinSOC% = <Integer ranging from 2 to 6. Typical is 6>

    LearnSOC% = <Integer ranging from 5 to 12. Typical is 7>


    What exactly do these values determine and how do I determine what these values should be set to for a given battery?
  • 0 in reply to Kyle Trenholm89
    TI__Mastermind 42535 points

    The app note I'm referring to is this one,

    The Max and Min refer to the ends of the curve fitting portion that's needed for the CEDV algorithm as you reach end of dsg and terminate voltage. LearnSOC is the value of RSOC at which your FCC gets updated. This necessarily has to be higher than Min and lower than Max values.

    The app note also highlights how you have to format the values to submit your logs to the tool.

  • 0 in reply to Batt
    Intellectual 285 points

    Batt,

    Thanks again for replying,

    That's the document I've been using as reference, sluub45b.  I don't see what you're referring to about "Trimming" the data anywhere in that document, unless you mean this line in Section 2.2:

    "Any text should be removed from files prior to submission"
    Which I assume would mean to remove the Date, Time, and Device info header in the log file?  Maybe the column headers as well as that will be communicated by config.txt?


    I am using the bqStudio GPC Cycle tab to take these readings.  Attached is one of the room temperature logs of a charge/discharge. What do I need to trim from this file before submitting?

    roomtemp_highrate[30C-30C].log

  • 0 in reply to Kyle Trenholm89
    TI__Mastermind 42535 points
    Sure, Kyle. I was referring to the fact that if you're getting data from bqstudio then you'll have to trim it. You need the log formatted as specified in section 2.2.3. You need the dsg cycles only at 3 different temps. Just leave Time, V, I and T. There should just be a single line header for the columns.
  • 0 in reply to Batt
    Intellectual 285 points
    Thanks Batt, that cleared up several questions about the logging process I had.
    Just to make sure I am understanding, I am taking the logs from bqStudio, and truncating the data to begin at the start of discharge, leaving the headers for Elapsed Time, Voltage, Current, and Temperature? Wouldn't the starting point for elapsed time being different on each log matter, or will your algorithms automatically offset those?

    Unfortunately bqStudio(1.3.80) has decided to stop logging during my 50C run today. Is there a place I can report software bugs? I started the GPC Cycle, High Temp High Rate. Charged battery at room temperature.

    Once the message box appeared to alert me to raise the temperature to 50C, I heated up the thermal chamber, then let soak for 2 hours to make sure everything was up to temperature.
    Clicked OK to proceed, attached load as instructed to begin discharge, now it is no longer writing to the log file. It actually looks like it stopped logging when the message window appeared with instructions to raise the temperature.
    The last log entry was from when I resumed logging after the 2 hour soak at 50C, so there's basically a 2 hour gap of nothing being logged, a single entry once I hit OK, then nothing.
    The status readout on the bottom right of the bqStudio was switching between "Polling Gauge Data" and "GPC Cycle Process", but now appears to be stuck on "Polling Gauge Data". Possibly a communication issue between the PC/EV2400/Gauge? Not sure what to do other than simply try again tomorrow and hope it doesn't happen again.

    The log file, BTW, was named roomtemp_highrate.log despite me choosing the High Temp High Rate Cycle, which is a bug I think I mentioned in another thread a few days ago.

    Is there an official channel to report these things?
  • 0 in reply to Kyle Trenholm89
    TI__Mastermind 42535 points
    The tool will offset the time. This is because the end time for each dsg matters only relative to its own start.

    The software engineers scan the forum here for bugs. So, I think that's covered. Thanks for telling us this here, we will also notify them that there may be a bug.