BQ40Z80: Learning status not moving from 05 to 06

Hi Krishna,

It seems like the gauge is conducting proper resistance updates during the discharge, so this confirms that the discharge rate and chemID are suitable in this situation. The update status here seems to be caused by the Qmax calculation being invalidated, since REST is becoming set signifying that the cell voltage is relaxed and taking OCV measurements, however VOK still being set is showing that a qualified OCV measurement has taken place. The typical reasons for invalidation can be found below:

The temperature and voltage criteria are OK based on the log file, however it seems like there is a CUV protection being triggered after the discharge. Can you please alter the protection thresholds and try again to see if this is affecting the Qmax update?

Regards,

Anthony

Hi Anthony,

I am working with Krishna on this project.

Anthony said:

however it seems like there is a CUV protection being triggered after the discharge

In our design, we are not using the discharge FET to control the discharge and hence we usually keep the CUV protection off because it would not have any effect. We are using our Electronic Load's software to cutoff the discharge when the battery voltage becomes low enough.(15600 mV in this case). Hence you would have noticed that there might've been the case that even though the CUV bit was set but the current was flowing through the gauge.

The log that we provided was of the fourth discharge cycle we did on the cell. In all the previous cycles, we kept the CUV protection off because it was not needed(We have completed multiple learning cycles this way). Since we were not getting past the LStatus of 0x05 after discharge, we decided to turn on the protection in hopes that maybe there is some outside relation of the CUV bit with the learning cycle which is not present in the TRM.

Hi Bhavil,

Running the voltage to the CUV value rather than the Term Voltage value should not process a difference in the way the Qmax update is calculated, however we would recommend discharging to the Term Voltage value.

Would it be possible to see the relax period prior where the LStatus changes from 0x04 to 0x05? Since the resistance is being updated successfully, this change would be conducted in the same fashion since it is reliant on the Qmax, so it would allow us to see if there are any differences between the two.

Regards,

Anthony

Hi Anthony,

My Term Voltage is set to 15600 mV, which is the point I am discharging my battery to. I will try to increase the term voltage to 16200mV and discharge it the batttery to 15600 mV just in case.

Anthony said:

Would it be possible to see the relax period prior where the LStatus changes from 0x04 to 0x05?

It would be a little tough for me as I do not have the log file for when the LStatus changed to 0x05. I will start another cycle by changing the Term Voltage and see if we succeed. If not, I will reset the gauge and try to start again and provide you with the full log.

Edit: I just checked my Term Voltage and it was set at 16200 for all the cycles, so I doubt that is the reason.

Hi Bhavil,

Understood, please share the data for the full log file so we can look into potential reasons that one Qmax update would occur but the second would not.

Regards,

Anthony

Hi Anthony,

We attempted one more charge cycle and the LSTATUS did not update from 4 to 5. The log has been attached.
Will try to do the learning cycle once again and in the meantime, do look into the log and let me know if you find anything.

Charge 1.log

Best Regards,
Bhavil

Hi Bhavil,

In the sent log file, the cell is not in a long enough relax state between the charge and discharge for the cell to reach a fully relaxed state to take the OCV measurement, which in the log file it seems like the relax period is only a little over an hour. This can be seen from the REST and VOK bit not being in the correct state when the discharge begins. We would recommend at least two hours or when the REST bit becomes set, along with the VOK bit clearing.

Regards,

Anthony

Hi Anthony,

My mistake, I sent an older logfile. Please find the log files from yesterday and the GG file here. The first log is of the charging and a rest period of about 3 hours

p30.gg.csvCHG log.log

Hi Bhavil,

Has there been any current calibration done on the device? There is a large deviation between what is being seen from the Current() and Cell Current() registers. Can you also go into depth about the charging load in use?

Regards,

Anthony

Hi Anthony,

I am using a current scaling factor of 4 and hence you might see this difference. I too noticed that the Cell Current() register does not follow the scaling factor and shows the actual current even if I am scaling down the current.

I am using a regulated DC supply to charge the battery. DC-3002 from HTC to be precise.

I did a charging yesterday too(log is attached below) I did notice the VOK bit clearing up, but this time the Lstatus did not update to 5. The log is a bit longer as I left the log on overnight.

CHG log 3.log

Hi Bhavil,

Thank you for confirming, Can you please confirm that all of the scaling in the .gg file is done correctly? Can you also share the actual cell details so we can compare the scaled values?

Regards,

Anthony

Hi Anthony, yes the scaling is properly set. I am using Molicel's P30B cells.

Hi Bhavil,

Can you please confirm the prescaled design capacity of these cells so we can look into the configuration?

Regards,

Anthony 

Hi Anthony,

The official data sheet of the cell says its 3000 mAh. My battery is 6s1p

Hi Bhavil,

Thank you for the confirmation, can you please try altering the current Qmax values prior to the charge to the set 750mAh seen for the design capacity? I would like to see if this is occurring due to a large change in the Qmax value.

Regards,

Anthony

Hi Anthony,

I tried doing the same but still no luck. Please find the log below. Another interesting thing about the log is capacity calculation. As you can see in the log, the charging started when the Remaining Capacity was 2 mAh and charged till it equalled the "Calculated" full charge capacity of 706, and the charging continued even after both of them were equal. However as soon as I hit VCT, the full charge capacity dropped to 620, even though the gauge itself calculated that it gained more than 620 mAh throughout the charge.

5282.charging.log

Hi Bhavil,

Understood, thanks for confirming. Just to confirm, between each of these test does the process include programming a fresh version of the .srec to the device?

Regards,

Anthony

Hi Anthony,

The gauge has the latest firmware uploaded in it. No, I am not re-programming the .srec file everytime I start a new cycle

Hi Bhavil,

Sorry for the delay, would it be possible to attempt running this using the non-scaled values of the cell to see if there is any difference in the performance of the qmax update?

Regards,

Anthony

Hi Anthony,

I can try it for the sake of it, but the end application will require scaling so I would have to repeat the cycle again for my application

Bhavil Nagar said:

Another interesting thing about the log is capacity calculation. As you can see in the log, the charging started when the Remaining Capacity was 2 mAh and charged till it equalled the "Calculated" full charge capacity of 706, and the charging continued even after both of them were equal. However as soon as I hit VCT, the full charge capacity dropped to 620, even though the gauge itself calculated that it gained more than 620 mAh throughout the charge.

Also do you have any explanation why this would happen? It happened a couple of times after I mentioned this as well.