BQ34Z100-G1: SOC when new battery plugged

Hello Antoine,

The gauge started off with learnt data and had limitations on how much new "learning" is possible because it thought that the gauge had completed learning cycle.

Replace this step "1- Flash the old image" with "flash the default srec firmware"

All versions of default firmware are available here www.ti.com/.../BQ34Z100-DEVICE-FW

Thanks for your answer. Just to clarify, by doing those steps ,

Antoine Dorel said:

1- Flash the old image
2- Change chemID
3- Import all flash parameters from the new image
4- Reset Update status and cycle count 
5- Generate a golden file (this golden file is named "fake new" after)

we are not intending to run a full learning cycle from scratch. Just to generate a Golden File that should be better thant the one we genertaed after the legit procedure ("new" golden file). How starting from a default FW instead of another should change anything ? 

By the way, the "fake new" Golden File produces incorrect results also. We had the chance to test it in our product last night. 

Another question : Is it possible to have a succesfully completed learning cycle with bad results ? I guess it is. It seems like the SOC estimation based on voltage during the fisrt OCV is wrong. Do you have any idea why ?

Hello Antoine,

During learning, the capacity is also learned and a number of internal values are updated. Starting from default ensures that the values are good starting points. The old image may have values that do not allow the new learning to converge properly.  The learning cycle may have completed because conditions were met, but there may be a mismatch between the internal and visible values that cause accuracy issues.

Ok I get your point.

If we do a new learning cycle we will definitly use the default FW to fully reset the chip (by the way it's a shame that it's not stated in the learning cycle procedure). 

But, the problem doesn't seems to be here as we did the learning cycle on a brand new chip to avoid this kind of things (we didn't know at the time we were able to reset it). So the "new" golden file has been obtained with good start parameters.

Another element to discuss : 

After flashing the gauge in the final product, we send the IT EN command as per stated in the DS. Our understanding is by doing so we force an OCV reading, which forces at least a SOC estimation and at best a Qmax update, correct ?

What if when doing so the battery is not in a RELAX state ? The OCV should not occur or at least not be qualified. This is what we observe.

If IT EN is sent when CHARGING, the gauge is never able to recover to a correct state of charge (old and new image the same). If IT EN is sent when in RELAX, the SOC seems to be correctly estimated on both images (we are running long tests at the moment to verify this). 

Do you confirm ? What is the expected procedure ?

The IT enable command enables the IT algorithm which tries to get an initial rough estimate of capacity. A relaxed battery will give a very good estimate. When charging, the algorithm cannot get a qualified reading, so it will have a lot of error. The errors will go away after a few cycles.

Make sure not to charge the battery when IT EN is sent. Even a battery that was charged/discharged just prior to sending IT enable will introduce errors. Is there a reason IT enable cannot be sent before charging?

Ok, so we got this right. The problem is we never saw a SOC  returning to normal after running a full charge/discharge cycle, maybe it needs more  cycles but anyway this is not the behaviour we want to have.

Unfortunnatly yes, the production line has been designed for a while now and we don't want to change the process just because we change the battery supplier. I understand that the expected procedure is to have a relaxed battery so the OCV reading should be qualified right away but we don't explain why we have a difference between old and new image.

You will find hereafter the 2 images (v2005 being the old one, v2023 being the new one) and the associated log when flashing the gauge. On both cases the setup is the following :

- The battery we use is the same for both tests and is globally relaxed

- We plug the usb cable of our product to start charging the battery (around 2A or less)

- Flash the FG

- Send IT EN

- Send Reset

- Unplug the cable

SOC of both images is wrong right after but within few minutes the OCV happens on the old one and get the SOC back to normal, which is not the case with the new one.

Do you have any leads ?

Regards,
 logs_and_images.zip

Hello Antoine,

I analyzed the log and think that the golden image ffor the new image may have been generated without setting Update Status to 2.

TRM reference 3.2.10 Update Status

Can you check that?

Yes and no.

The procedure was the following : 

1- Complete the learning cycle until learning status was 0X06

2- Generate the Golden file

3- See that in SLUA903 conclusion on the last page (not on the section about generating the golden file) 

Before saving the Golden File, set Update Status to 02 to disable IT gauging, set the Qmax Cycle Count to 0, and set the Cycle Count to 0. For a pack side gauge, this ensures that when the pack is assembled and gauging and lifetime data is enabled, the cycle counts start from 0

4- Change the Cycle count in Configuration and Gas Gauging section to 0, set UpdateStatus to 0x02

5- Regenerate the Golden File

Here are my 2 questions : 

- I guess if you were able to ask us that it is because there is a difference in the golden file that we cannot see in BqStudio. Do you confirm ?

- Do we need to set the cycle counts to 0 ? The old golden file doesn't have that, when flashing the gauge the cycle count are 2 and 1. 

Regards,

Hello Antoine,

Use the golden image from step 5. I saw that IT was not enabled in old log, but was enabled in the new log ITEN bit.

Not setting the cycle count to 0 does not impact any other functions, so no worries there.

The golden image at step 5 is the one we are using from the begining (the "new") image. So this is not the problem.

I don't understand where did you see IT is enable as when I'm flashing a gauge with either of these images, the Qen bit is low. 

Am I missing something ? 

Hello Antoine,

I think what Shirish is mentioning is to make sure update status is 0x02 for the golden image, once it's in the final product on the first boot the host sends the IT_EN command to start gauging at that point.

Sincerely,

Wyatt Keller

Hi Wyatt,

It is the case as I described, the problem is not here :/ Any ideas ?

Hello Antoine,

The issue you're having is that after the IT_EN is sent the SOC is incorrect and the new version of your firmware settings it does not correct after a few minutes?

As Shirish mentioned the gauge expects the voltage is an OCV when IT_EN is sent, if it is not then the IT_EN should not be sent until it is. IF you let the battery properly relax before sending the IT_EN command do you get better results?

If you have changed some of the smoothing like RELAX_JUMP_OK then it may never get corrected because of your new settings preventing any RSOC adjustments in relax.

Sincerely,

Wyatt Keller

Hi,

Nothing concerning smooth mode have been changed if you compare in the parameters files I uploaded earlier. 

Yes, sending IT_EN in RELAX mode gives us better results, but again, this is not the current manufacturing process. Even if we were able to change the manufacturing process, the problem is I don't trust this new image because it has a different behaviour from the previous one. We don't known how the state of charge will be in the product life. 
Our product are placed outdoor, for long period of times, several months to several years. A lot can happen to the battery and we want to track that properly. 

Hello Antoine,

Sending IT_EN in relax mode should give you good results, not just better. If that is not the case, then there may have been some issue with the new learning cycle. I think you may already have checked the chemID. Can you confirm that the chem ID command from both images returns the same ID?

No the chemIDs are not the same and they are not supposed to be. If we had not changed the battery chemistry we would not have to do a learning cycle again, correct ?