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: Learning Cycles returning unreliable results

Part Number: BQ34110
Other Parts Discussed in Thread: BQSTUDIO

Hello,

This is a semi-continuation of a previous post: https://e2e.ti.com/support/power-management/f/196/t/852468

I have been running learning cycles on my 17x12 V, 8Ah battery pack. At first I was getting values of 0 or 1, which I was told is okay since all the values are relative, and I should only be concerned about the change in Rcell rather than the value itself. I have automated a cycle which charges/discharges the battery pack and takes Rcell measurements every 2 or so discharge/charge cycles. I noticed that the learning cycles were returning a value of 6553 consistently (3 or 4 times in a row). I played around with data flash settings and noticed that when I set the Rcell High Temp Coefficient to 0 (it was previously at 267), the learning cycles returned values of 1 or 0 again. BUT occasionally (even with the temp coefficient at 0) the learning cycle will return a value of 4074 or 6553.

Voltage and Current gauging on the chip is very accurate, which is all that should matter according to all the technical documentation that I have read. So what is the problem? Why are the values either close to 0, or in the 1000s? The end of service determination is the whole reason we got this chip, so if it can't even do that reliably, it's useless.

Thanks,

Colin

  • Sorry to hear that Colin. How did you determine the battery model/chemID for the device?

  • Hi Andy,

    The BQ34110 does not use a battery model or ChemID, it uses TI's CEDV algorithm. From what I understand from technical docs and forum questions, the CEDV gauging module is completely separate from the end of service determination module on the chip. And even then, we have found our CEDV parameters, have programmed them into the chip, and have tested the CEDV parameters to confirm that they work. So there's no reason why the end of service determination algorithm should be returning such varied results because of that.

    Thanks,

    Colin

  • Hello Colin,

    Are you logging using bqStudio + EVM for these tests? If so, are you able to share the log file and your srec file with us on this thread?

  • We are not currently using bqStudio + EVM but we are logging these tests using a F28335 micro. I've attached some logs and the .srec below:

    3005.L-logfile004.csv--this log returned 6553

    5037.L-logfile033.csv--this log returned 0

    1464.L-logfile036.csv--this log returned 5012

    These logs are in chronological order, so this isn't natural aging of the battery that causes these numbers.

    And this is our current .srec file (e2e doesn't let me post .srec files so I converted it to a .txt, hopefully this doesn't mess anything up):BQ34110-12-10-19.txtIf that doesn't work, this is the gg.csv: BQ34110-12-10.gg.csv

    Although we are not currently using bqStudio, our previous test setup before this one did utilize bqStudio and we ran into the exact same problems.

  • Let me check these files. Will let you know if we need more info from you. 

  • Your log file shows that the learning status has LDONE = 1 at the end. This means that the gauge will have tried to calculate RCell. If RCell is zero, then something caused that gauge to either calculate a negative resistance or a zero resistance. The gauge will not store a negative RCell value and will force RCell to zero.

    The gauge will calculate RCell by measuring the difference in cell voltage at the end of the learning cycle load before it turns off the load (first measurement) and after the cell relaxed (second measurement).

    Note that your log file with a non-zero RCell value shows that the learning status was 20(decimal), which is 0x0014, which means both the LCMD bit and LRLX bit are 1. So the gauge is still in a learning cycle and "waiting" for the cell to relax (but it isn't waiting for more than one second as your cell is always in relax - see my explanation below).

    Your log file with a zero RCell value doesn't show learning status = 20. It switches from 17 to 16 (0x0011 to 0x0010, never setting the LRLX bit). So it seems that the gauge "thinks" that the cell is immediately relaxed (it's actually the same as in your other log file but your log interval missed the LRLX bit because it will clear in one cycle in your incorrectly configured system - see below). So something goes wrong with detection of relaxation.

    In your "5037" log file, the last voltage at learning state 0x0011 (LCMD and LDSG) is 222972 and the voltage at learning state 0x0010 (LCMD only) is 222972. So LRLX was already cleared and the gauge thinks the cell is relaxed. However, as there is no difference in voltage, the resistance will be zero.

    In your "3005" log file, the last voltage at learning state 0x0011 (LCMD and LDSG) is 221340 and the voltage at learning state 0x0014 (LCMD and LRLX) as well as 0x1000 (LDONE) is 221442, hence the gauge will calculate a non zero RCell.

    --> The main problem in your system is due to the voltage measurement and how the gauge determines that the cell is relaxed.

    Your gg file shows a discharge detection threshold of 350mA. However, your learning load is significantly less: 132mA. Therefore the bq34110 gauging mode (this is not the same as learning cycle status) will never enter "discharge" state and always stay in relax state. Hence the "cell relaxed" flag that the gauge uses to set the LRLX flag (and which controls when the gauge takes the second voltage measurement for RCell computation) is going to be "true", causing the gauge to take the second voltage measurement within a gauge cycle (1 second). So if the cell voltage doesn't change (or changes very little) in that second after turning off the load then you'll get RCell = 0 (or something very small).

    --> Please change the Discharge Detection Threshold from 350mA to 100mA so that the gauge will exit relax at the start of a learning cycle and wait for a proper relaxation at the end of a learning cycle. This should fix your problems. I would also check why the voltage looks so choppy during the cycle but the main problem is the incorrect configuration for gauging state-change thresholds (relax/discharge).

  • Hello Dominik,

    Thanks very much for your help!

    We tried your recommendation and changed the Discharge Detection Threshold from 350 mA to 100 mA. We tried another learning cycle and after the pre-relax phase, the [LFAULT] and [LUCD] bits were set. I remember that we had this LFAULT/LUCD problem happening previously which is why we changed the discharge detection threshold to 350 mA, and this seemed to fix that problem. 

    That being said, what you're saying makes sense- I notice now that in the logs I posted, in the Gauging Status register the [REST] bit is always set, even during discharge. However, I'm not sure why setting the discharge detection threshold to 100 mA should make the learning cycle fault. It might be that these two problems aren't actually related. Do you have any ideas about why this is happening?

    Thanks again,

    Colin

  • To add to Colin's post, attached is a learning cycle logged today with the discharge detection current set to the recommended 100mA. 

    Learning Log.xlsx

  • Your latest log file shows that the gauge (EOSLearnStatus) changes from 0x0011 to 0x0014 at time 3437s. Current changes from -132mA to -40mA, which will trigger the DischargeRelaxTime test. DischargeRelaxTime is 60 seconds in your gg file so the gauge (note that there's a distinction between gauge state and EOSLearnStatus - EOSLearnStatus is now waiting for relax; it already exited EOS discharge state at time 3437s) will stay in "discharge state" for another 60 seconds. You can see this in BatteryStatus(), which has bit 0 (DSG) set to 1 until time 3497s (60 seconds later).

    The EOS learning state machine, however, requires that the current is zero when it waits for relax. It specifically checks if the gauge state is still "discharge" (which it is for 60 seconds after the current crossed the Quit Current (your config = 80mA) threshold) and if it is, it will set the LUCD bit. This happens at time 3441s in your log file (all times rounded) because the current isn't zero (it's -40mA).

    --> Please make sure that the current is zero or set DischargeRelaxTime to 0s (I don't recommend the latter for a real system as this can interfere with gauging if there's a short current drop that shouldn't change the gauging state and in any case, if your current is not zero, the gauging algorithm will not qualify the relax phase for a very long time (up to 5 hours) for EOS resistance updates if the voltage isn't stable (which it may not be if you still have a 40mA load current)).

  • It makes sense that the 40mA is an issue. In this setup there's no way to avoid that, but since it's just for testing setting the DischargeRelaxTime to 0s shouldn't be an issue. It does take quite a while to qualify the relax but it seems to be working. Thanks so much for your thorough answers!