BQ4050: Fuel gauge chip has drift and huge error in SoC

Hi Chris,

This could be a discrepancy between your config file and how you are intending to use the battery in your application. It would be helpful if you could send me a BQStudio .log file of this behavior occurring at both the top and bottom voltage range of the cell to investigate further. With the info I have now there are quite a number of possible causes for this behavior. In general, using purely the voltage level of the cell as an indicator of SOC is not accurate because any load on the cell can change the voltage drastically. Temperature can also play a huge role in the voltage as the internal impedance will vary across temps. 

I would suspect that the SOC is reporting 0% because bat voltage drops below the terminate voltage level but I will need a log file to confirm.

Best Regards,

Jackson

Here is a log file, but the termination charge is taking a while so I may upload another later.  charging_top_end.log

Hi Chris,

Looking at your attached log file, I do not see any uncharacteristic behavior. The gauge is coulomb counting up while charging and I see RemCap slowly rising. FullChargeCapacity is set to 4144 and RemCap climbs to around 2068 which is why you see SOC around 50% here. If you continue charging after this and can send me that extended log that would be great so I can see how SOC approaches 100% (hopefully no jump). But again, this log currently shows expected behavior from what I can see.

Best Regards,

Jackson

Here is another file.

charging_top_end2.log

Shouldn't the SoC go to 100% at full cell voltage and the SoH be adjusted if the capacity is not as stated?

On the bottom end I see the SoC stop at 0% (which is @about 3.4V) and then the battery continues to provide plenty of power for awhile as the cells work towards 3V.  

C

Hi Chris,

I need a much longer log file to obatin any possible causes for this behavior. This one never changes RSOC. I am interested in various gauging parameter values from when the battery is still receiving a constant current charge all the way until charge fully tapers out from the charger. Ideally, a full chg/relax/dsg/relax cycle would be great and should tell me everything I need to know.

Best Regards,

Jackson

This is hard to do because our application processor needs to be talking over the i2c bus in order to control load and charging.  The constant scanning and logging disrupts it and makes it very hard to get a whole cycle without something getting misconfigured or undesired operation.  Given this cycle would last for many hours I don't have much confidence.  I'll see what I can do

Do you have any recommendations or theories yet?

Understood, in the meantime can you provide me with the datasheet of the battery cells you are using? I want to compare to see that this isn't a config issue causing FCC to be incorrect and lead to this SOC issue.

Also, are you charging directly after a reset? with the CEDV gauge, it is good to completely discharge after a reset first. This will remove the error caused by the initial voltage lookup and allow the coulomb count to be accurate when charging.

Best Regards,

Jackson

Here is the data I have so far.  It was quite a mess to collect.  It involved starting and stopping the data collection several times as I un-froze the application processor.  It usually wasn't very happy about that sequence.  None the less the application processor controls charging and a few other things so it was necessary.  

I also noticed that the bq studio app and associated log file seemed to have bogus data in some places.  The cell voltages for cells 2 and 3 seemed to be frozen toward the end of the data collection.  My application processor gets those values from the gauge also and it had correct values that I verified manually.  

I will continue to collect data as the charge tapers to zero but this is a very slow process.

C

long.log

long2.loglong3.loglong4.log

The last file is attached which I trimmed of the data where it sat overnight to reduce file size. 

taper.csv

Sanyo-Spec-NCR18650GA.pdf

We've used a variety of cells, but the ones attached are the set we're going with now.  

As for charging after a reset what do you mean by reset?  I tried a few of the reset commands in the past and they didn't seem to help the situation.  

Hello Chris,

It looks like the gauge is correcting near the EDV based on the voltage corrections, this is how the CEDV algorithm operates. Did you get the best matching CEDV coefficients using the GPCCEDV tool?

Also it looks like your taper is well before the gauge thinks there is full charge, is this an aged cell? For CEDV you need to have one full cycle once in awhile to updated the FCC with a qualified discharge. If you don't ever get a qualified discharge the gauge accuracy will decrease over time since this is how it corrects for aging.

Sincerely,

Wyatt Keller 

Hi, I am not able to do all the temperature dependent cycles on the battery so can't do the full dataset the tool asks for.  Our original config was for a slightly different gauge (BQ40Z50) but that part was no longer available so we had to switch to this one.  I updated the EDV0  (2600), EDV1  (2792, 3% number), and EDV2  (2991, 7% number) parameters but this did not fix the issue.  When it charges it never resets to 100% SoC. 

Is there another parameter I should be looking to adjust to fix that resetting at the top end issue?

C

The cells are not aged.