BQ27541-V200 Accuracy at Low SOC

I ran another test with a 6.4-Ohm constant resistance test load and the GG reported 0% SOC when the voltage reached 3.27V. The battery continued to support the load for another 3 minutes before reaching 3.0V cutoff. This is an error on the conservative side and is acceptable. Since the reserve capacity is 100mAh, the run-time after SOC reports 0% should ideally be 100mAh/500mA*60min/hr = 12minutes. The Impedance Track Algorithm is still off significantly, but I can live with a conservative error, not with an optimistic error. 

Can you indicate at what voltage do the protector FETs open?

Does the gauge lose power when FETs open or is the gauge directly connected to battery cell?

Can you describe the charger operation for this battery? I want to confirm that 4000mV is the right charge voltage setting for your application.

Over-discharge protection FET opens at 3.0V.

The GG does not lose power when FET opens; GG connects directly to cell.

The cell is from LG Chem, p/n LGC18650HB1, rated at 1500mAh. The specified charge voltage is 4.2V, but I reduced it to 4.0V to get longer service life out of the battery. The application requires just 350mWh per backup event (14W for 90s) and a five year service life, so I'm trading off energy storage for longer life. The charge current is 500mA and the charge voltage is 4000mV.

The charger is BQ24707A, constant current, constant voltage controlled via the GUI.

The original battery design used a charge voltage of 4.2V and the same issue was seen with "dead battery" when GG still reporting ~10%. The original battery did not have the learning cycle run, so I made sure the next revision of the battery (with 4000mV) had the full learning cycle. The only difference between batteries is the contents of the Data Flash and the process that was run before shipping.

Lance,

Do you have EVSW data logs and gg file logs of when you did the learning cycle that gave you the golden image?

Are you able to log in EVSW the complete charge-discharge cycle in which you are seeing the capcaity discrepancy at end of discharge?

Hi Mike,

I'll have to request the data logs and gg files for the golden image from our chinese supplier. I'll get those to you tomorrow.

I do have logs for the charge-discharge. Can I email them to you?

Measuring the power output as seen by the battery (Voltage*AveCur) shows that the power is going up as the battery voltage goes down. The nominal power is 14W, but the actual power is 14.6W and steadily rising until very close to EOD the power starts rising more quickly until it hits 15W or more. This is a small increase but might help explain some of the discrepancy. I can send you some pictures if you give me an email address.

It's not that I'm overly concerned with having great accuracy; I just don't want to err on the wrong side. It's ok to have extra holdup when the GG reports 0% capacity. It's not ok to report 10% capacity and then have the battery suddenly die. I could pad the reported SOC by telling the host that the battery is dead when SOC reports 10%, but what will happen as the battery ages and the battery impedance creeps up and the Full Charge Capacity is reduced? Will the battery die when the GG is reporting 20% SOC? I may have just moved the problem and not solved it. Same goes for just increasing the reserve capacity - may not be a good long term fix.

Mike,

I have attached the golden image leaning log for the battery. 7217.Jurojin_golden learning.xls

Let me know what you think,

Lance,

Can you add the dataflash gg file from after your last discharge? I want to see if any impedance learning has occurred.

Can you confirm if the gg file that is shown at the top of this thread is from before you started any cycles?

Mike,

I attached a running log of all the gg files that I have collected over the various charge-discharge cycles. The gg file that is shown at the top of this thread is in one of the middle columns. The very first gg file is in the leftmost column (labeled "at receipt).

7848.PDD Battery GG DF Config Version snDF1.xls

Mike,

Sorry, the original gg file for battery s/n DF1 is in column "C". Column "B" is a prior revision of battery. The green highlights show where data has changed value.

1732.PDD Battery GG DF Config Version snDF1 b.xls

Mike,

I updated the spreadsheet for a little more clarity. Column "B" is the DF in the first prototype (so-called P0). There were issues with these first batteries with poor accuracy at low SOC, namely reaching EOD when the SOC was ~10%. I thought that this error was due to the fact that our chinese supplier did not go through a full learning cycle and there were potential issues with the golden image. I came up with new proposed DF for them (column "C") and told them to use these new values and run through the whole process again, regenerating the golden image and going through a full learning cycle (I also reduced the charge voltage from 4.2V to 4.0V to gain better service life). Column "D" s/n DF1is the DF from the battery pack that I received back. I went through some charge-discharge cycles and recorded the gg files, but the issue of EOD prior to 0% SOC is still present.

Lance,

Can you clarify which of these two conditions are occurring:

1. You reach end of discharge voltage but gauge was still reporting ~10% SOC or.

2. The gauge reaches 0% SOC reporting but you estimate that about 10% of remaining capacity continues to discharge until you finally reach end of discharge voltage.

I ask because I'm maybe confiused. From your claims I understood that it is statement number 1 but when I look at the log that you sent it shows statement 2.

Given that you are  going to run a golden learning cycle again and your application is expected to charge to 4V only, you should follow this procedure for golden learning cycle:

1. Discharge at C/5 rate to 2.9V, allow 5 hour relaxation.

2. Enable IT

3. Charge to 4.2V, relax 2 hours

4. Discharge at C/5 rate to 2.9V, allow 5 hour relaxation.

5. Charge to 4.0V, relax 2 hours

6. Discharge at C/5 rate to 2.9V, allow 5 hour relaxation.

Also make sure that DSG Current Threshold is left at 60 instead of 1000 in the dataflash.

Mike,

Your original understanding is correct: The EOD is reached but gauge is still reporting ~10%. I attached a typical log file which characterizes the issue.

The log file that was attached prior is the golden image log (from the chinese supplier) that does not exhibit the issue.

4152.Battery_snDF1_cycle8.xls

The Over-Discharge FET trips at 3.0V, so does the protection circuit need to be changed to 2.9V or something else under 3.0V? Or can the golden learning cycle process be adjusted to discharge to 3.0V?

You may adjust the learning cycle to 3V.

Mike,

Two Questions:

1) When the golden image file is created, do I just import this file into the Data Flash and resume charge-discharge testing? The golden image is being created by our chinese supplier and they will send the file to me. I will not have the original battery pack that was used to create the golden image.

2) For the impedance track algorithm, the Full Charge Capacity is based on the amount of charge passed from full charge to the point where the voltage meets the Terminate Voltage, which is set to 3.0V. However, the over-discharge protection FET is also set to trip at 3.0V. I'm wondering if the issue I'm seeing is that due to slight tolerance differences the protection FET activates before the GG detects that the terminate voltage was reached. Once the protection FET opens, the voltage will go up and the Terminate Voltage will never be reached. The GG will not immediately update Full Charge Capacity as the second data point was not captured. It seems to me that if the GG detects voltage<Terminate Voltage, then the SOC should be set to 0% and Remaining Capacity should be set to 0mAh. Does the Terminate Voltage always have to be set higher than the over-discharge protection setting and since that is not the case for this pack, is this the source of my error?

Can I go in and change the Terminate Voltage and retest, or does changing the Terminate Voltage require the golden image to be regenerated?

Answers:

1)  If the golden image was created using the guidelines established in bqEasy and in our application notes then you must enable Impedance Track (Command 0x0021 to the Control register) before performing any accuracy tests. You do not need to use the actual battery that was used to create the glden file as long as the battery that you use is of the same model and manufacturer. You can confirm that IT is enabled by checking that the QEN bit in Control Status is set.

2) Typically battery protection circuits will be selected so that they trip on undervoltage condition between 300-500mV below the minimum system operating voltage (Terminate Voltage) It would be ideal that you allow some gap between Terminate Voltage and protector undervoltage threshold so that you do not shutdown the system because the protector open (not allowing your system to properly prepare for a shutdown). You can change Terminate Voltage and send a reset to the gauge. It does not require to relearn the golden image.

It would be interesting to see how your results are affected by this change.

Interesting indeed - it worked!

The over-discharge protection voltage threshold is fixed in hardware at 3000mV, so I increased the Termination Voltage to 3200mV. I used a lighter 4W load to make sure the voltage was decreasing slowly so that the GG could detect the Voltage crossing the Termination Voltage before tripping the protection. At the crossing, the Remaining Capacity and Full Charge Capacity make sudden corrections, as expected. Other parameters make corresponding corrections, so it looks like it's working. I'll play around with it some more to make sure that the full 14W load can still be accommodated, but I don't expect any issues.

I guess this means that I need to perform a full discharge as part of the production process. This shouldn't be a problem, but I'm not sure how well the GG will perform over the years as there will never be a full discharge again. I'll run some life tests under various loading conditions to see how well it fares.

thanks Mike for your help and you can go ahead and close the issue.

7853.Battery_snDF1_cycle13_Term=3200mV.xls

Hi Mike,

The testing with a 14W load showed that the Termination Voltage needed to be increased from 3.2V to 3.3V as the logged voltage never reaches 3.2V before the battery protection FET opens. I'm guessing that with the 14W load the voltage is dropping too fast and the GG sample rate misses the minimum voltage, so FCC was not getting updated. I thought the GG sample rate was 1S/s which should be plenty fast enough. The logging rate is every 10seconds which should have nothing to do with GG sample rate, but perhaps it does? Does logging have an affect on GG sampling speeds? In any case, 3300mV is a good value to use for Termination Voltage.

Battery s/n DF1 (the battery that I have been doing all my testing on) worked well with the new Termination Voltage. After the full discharge the RemCap is just 15mAh which is an acceptable level.

Our Chinese supplier created a new golden image per your recommendation with charge up to 4.2V, discharge to 2.9V, charge to 4.0V and discharge to 2.9V. I imported this file into another battery pack s/n DF2 but the results are no better than what I had previously. The previous error when the battery was completely drained was RemCap=130mAh and the new result is RemCap=156mAh at the point of loss of power. I don't understand when I completely drain a battery why the GG can not figure out what the FCC is. The GG knows the starting point because the battery is fully charged and it knows the total capacity removed up to the point when the Termination Voltage was reached. The total capacity removed is the FCC. The GG seems to have it figured out, but then as soon as the charger is turned on the FCC reverts back to what it was before. I have attached the log, so can you tell me what is going on?

7848.Battery_snDF2_cycle6_Golden_Image&Term=3300mV.xls

thanks,

Lance