BQ34Z100-G1: NiMH battery pack: SOC=0 issue

Let me take a look at your gg file and see if there is anything wrong with the settings.

Hi Dominik,

thank you for your support.

The battery pack has a 5400mAh capacity and the storage was a few weeks (7-8) long. So an error of some mAmps in the current reading (e.g. due to a non-precise offset calibration) can lead to a SOC decrease down to zero. Is that evaluation correct? Why did you mention this could be a problem just in case the BQ34 is in the sleep mode?

We have another old sample of the battery pack that was in our lab since last summer and we leave it at rest for several month. It doesn't suffer of the SOC=0 issue. Such a pack has two differences compared to pack where we found the problem:

1. its "update status" is at 02 instead of 06 (that was because of a test we did in the past). Can such an update status value affect the behavior we are discussing about?
2. before to leave such a pack at rest on last months, we cycled it several times. Does cycling the pack can improve the robustness and stability of the SOC estimation?

Moreover, our customer has found another battery pack that was not in warehouse, but in permanent trickle charge (200mA) for 2-3 weeks. It has been affected by the same problem of SOC=0. How does the trickle charge influence the BQ34 algorithm of SOC estimation? Could it create "strange" results like SOC=0? 

In any case, I would like to find a way to avoid such phenomenon:

1. Could your suggestion of disabling smoothing be a fix? Is that to be permanently applied or temporary, just in case we find a battery pack in the SOC=0 condition? How have we to se flags in the "Pack Configuration C Register" (SMOOTH, RELAX_SMOOTH_OK, RELAX_JUMP_OK)?
2. As mentioned in the above point 2, can a full discharge-charge cycle (or even more than one) after calibrating, IT-enabling and sealing the BQ34 (i.e. before to ship or store the pack in the warehouse) be a solution?
3. Because we have cycled a battery pack with the SOC=0 issue and, after a full discharge-charge cycle and several hours of rest, the SOC has automatically and gradually reached the correct value, can such an operation a possible procedure to recover any battery pack with the SOC=0 issue? (of course, on field such a procedure is not always feasible, so it wouldn't be the preferred solution)

I hope my notes are clear and we can find a valid solution. Of course, we are available to perform any test it could be necessary in order to understand and validate a solution.

Thank you again and best regards

Matteo

The gauge implements a noise filter for the coulomb counter, which can lead to a small offset error which will slowly affect total accumulated charge. In regular operation it's not a problem because it is dwarfed by real charge or discharge currents. In long time storage, this can deplete filtered RM (and hence filtered SOC) all the way down to 0mAh/%. The gauge is usually in sleep mode in this use case so that's why I mentioned sleep mode. Filtered RM (and SOC) will not auto-adjust to RM and SOC for an OCV reading in sleep (relax). If RM and SOC are not zero but filtered RM and filtered SOC are zero, then it is proven that the long time offset error accumulation is the root cause.

The configuration differences (update status and cycles) do not explain the long time storage 0% SOC observation because these differences are about QMax and Ra and neither will cause 0% SOC during storage.

The least disruptive method to fix this would be to issue a reset command after long time storage, if your system can detect long time storage.

Hi Dominik,

thank you again for your explanation.

You wrote: "If RM and SOC are not zero but filtered RM and filtered SOC are zero, then it is proven that the long time offset error accumulation is the root cause". How can I check for that?

• is SOC the SOC we are discussing about? It is 0
• is RM the Remaining Capacity? It is 0
• where can I find the Filtered SOC?
• where can I find the Filtered RM?

Here you can find screenshots of the Registers content for 3 packs with the SOC=0 issue:

Accordingly to your explanation, what does happen while the battery is in trickle charge condition, i.e. permanently (or long time) charged with a low current well above the full charge condition? As I mentioned in my previous post, it seems there is a case where we found SOC=0 after such a condition (instead than after a storage period).

Concerning the restore procedure, I will check again, but I'm quite sure I tried to restore the SOC value by sending the reset command to the BQ34, but without any effect. As I wrote in my previous post, I obtained an effective restore of the SOC value by temporary changing the Load Select parameter (from 3 to 1). Does it make sense or even the simple reset command should be effective?

Thank you and regards

Matteo