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.

  • TI Thinks Resolved

BQ34110: Learn FCC Update Limit

Prodigy 225 points

Replies: 25

Views: 623

Part Number: BQ34110

Hello again,

After running multiple logging discharge cycles, I have noticed that FCC never updates itself by more than 256 mAh. In the BQ34110 TRM, it says "FCC cannot be reduced by more than FCC Learn Down or increased by more than FCC Learn Up during any single update cycle". "FCC Learn Down" and "FCC Learn Up" are bolded and italicized, which I assumed meant that they are data flash parameters that can be altered. However, there is no such parameter in BQStudio, and there is no other mention of these parameters elsewhere in the TRM. 

Is it possible to increase the FCC Learn Down/Up limit to greater than 256 mAh? Or, if the parameter has only enough space for a 1-byte number, is there a way to turn off the limit entirely? I am asking this because it is clear that our batteries have a full charge capacity that is significantly lower than the Learned Full Charge Capacity reported by the chip (after fully charging, the RC value is approximately 5 Ah, while the learned FCC is approximately 7.8 Ah). I know that Learned Full Charge Capacity is a data flash parameter that can be changed, but I would rather let the chip measure it automatically, just in case our charger isn't working properly somehow. At the same time, I don't want to have to do 6 or 7 charging and discharging cycles because the Learned FCC can only update 256 mAh at a time.

Thanks again for any advice you can give.

Colin 

  • Hi Colin

    How large are expected FCC updates to your device?

    FCC learn Up and FCC Learn down are private parameters.

    Sincerely,
    Bryan Kahler
  • In reply to Bryan Kahler:

    Hello Bryan,

    Thanks for answering! While we are testing, the FCC updates seem to be quite large. Our battery only ever charges up to about 5 Ah RC while design capacity is 8 Ah (this is after only using the batteries for our GPC cycles). This isn't really our main concern, as we can change the learned FCC parameter if necessary. I'm more worried about when the batteries are used in their UPS application. The batteries are expected to rarely be discharged, if at all, and I doubt that the client would want to run periodic full discharge cycles. If the batteries have aged enough that FCC drops by 500 to 1000 mAh, then even after a recent full discharge, the learned FCC still won't show an accurate value, and consequently SoH and SoC will be skewed as well. In short, I don't know by how much FCC will change in between discharge cycles, but I would like to have an accurate FCC estimation if it drops by a large amount, say 500 mAh or more.
  • In reply to ColinY:

    After more testing, I'd just like to add that there seems to be a difference between the chip's remaining capacity counter vs. the actual nominal design capacity of the battery. Even after using a fresh battery and running a discharge and charge cycle, the remaining capacity never charges back up over 5.5 Ah when the battery is rated 8 Ah, even when the voltage hits around 13.5 V (we are using 12V, 8Ah batteries). If we discharge them again from this 5.5 Ah point, Time to Empty (TTE) and State of Charge (SoC) estimations decrease linearly and continuously, and TTE seems to be very accurate. However if we disconnect and reconnect the chip to the battery in order to trick it into thinking it is at 8 Ah, 100% SoC, the TTE and SoC will decrease linearly to about 30% SoC until it gets close to EDV2, then drops abruptly to 7% SoC and 5 minutes TTE.

    This makes me think that the 5.5 Ah, ~60% SoC value is more trustworthy. But since the SoC is always at 60% max, FCC will never be able to update since SoC needs to be near full for it to qualify as a valid discharge. And even if we can trick the chip into thinking we're at FCC of 8 Ah, running an discharge cycle will only update the FCC by 256 mAh. Should we be just setting our design capacity to around 5.5 Ah?

    It might be easier to understand with the logs. In this log we did a full discharge from full charge capacity, 100% SoC. Then we charged it back up, but it only reached 65% SoC. I realize that the current doesn't taper off, but the voltage is already high enough that RC should be much closer to 8 Ah.

    TestDCLog-4-9-19-823.log

    This log is a continuation from the previous log, when it started discharging around the same voltage as the first log, but only around 65% SoC. The RC, SoC and TTE of this log is much more continuous and doesn't jump abruptly.TestDCLog-4-9-19-1338.log

  • In reply to ColinY:

    Hi Colin,

    Thank you for the descriptive update. Due to current loading it will take some time to analyze these logs. Please expect another update by EOD Friday 4/19/2019.

    Sincerely,
    Bryan Kahler
  • In reply to Bryan Kahler:

    Hello,

    Just another update for whenever somebody gets the time to look into this problem: we charged the battery fully all the way to 100% capacity (close to 8 Ah) by using a power supply (instead of tricking the chip into thinking it's full SoC). The battery voltage peaked at about 13.5 OCV. We then started discharging from that point at full load (12A) and we had the same problem of the BQ34110 overestimating the time-to-empty and SoC values again (see attached log). At this point we are also wondering if our battery profile might be the problem. The CEDV calculator returned FCC OCV of 11.9V when it seems that our battery isn't full charge until it's closer to 13.5 V. I've also attached the battery profile and GPC logs to this post. FinalParams6s.zip

    Discharge7.log

  • In reply to ColinY:

    Hi Colin,

    With respect to the GPCCEDV tool, if underestimation is seen, for example, with a low temp high rate application, replace the low temp high rate log file with one at a higher rate and try rerunning the tool over the data.

    Looking through the nested zip files, I wasn't able to find the gg.csv file. If issues persist, could you please attach that as well?

    Sincerely,
    Bryan Kahler
  • In reply to Bryan Kahler:

    Thanks for the reply, I've attached the gg.csv file here: BQ34110GGCSV.xlsx We've seen underestimation at both lower and higher rates at room temp, so we're redoing both logs. I'll let you know if there's any improvement.

  • In reply to ColinY:

    Hi Colin,

    Thank you for the update.

    Sincerely,
    Bryan Kahler
  • In reply to Bryan Kahler:

    Hello Bryan,

    Finally got done with re-characterizing the battery. We actually redid all 6 logs- we thought we hadn't charged up the batteries the full way during the first set, so that might be the problem. With the new characterization, we are seeing a reduced error, but the TTE is still dropping from 11 minutes to 3 minutes. This is our characterization logs:

    NEWGPC3.zip

    This is the parameter zip file we received from TI:

    NEWGPC3-report.zip

    This is an example discharge with the new parameters:

    Discharge GPC3.log

    I tried messing around with the FitMaxSOC% and FitMinSOC% in the config. I haven't actually seen any posts or info about how to select these numbers. From what I noticed, the SOC Error% that are returned from TI vary about 1-2% when adjusting these values. It seems like with a lower percentage error, the RC/TTE values don't drop as heavily. For example when the SOCerror% for roomtemp_lowrate was 1.77%, the TTE dropped from 16mins to 3 mins once it hit EDV2. When the SOCerror% was 0.73%, the TTE dropped from 11 mins to 3 mins. I'm not sure if this is correlation or coincidence.

    The problem with this is that it's impossible to get all 6 condition (temp + rate) error % under 1%. If I change FitMax/Min so that one condition error goes down, another condition error will go up. It might be possible to change the CEDV parameters dynamically based on discharging environment conditions, but this would be a pain to code.

    I'm interested to hear any advice or suggestions you can give. Thanks for your time.

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.