BQ20Z65-R1_BQEVSW-SW: BQ20Z655-R1 Lost track of state of charge

Hello Tony,

Can you help us understand "the display does not change".

The display is an LCD with 5 bars.  5 bars are a capacity of 95% or greater.  16.8V is full voltage.  this is the second time we have had a pack show 5 bars and the pack measure 12.3V or lower.

Hello Tony,

Thanks. Is this a 4S pack?

Yes, this is a 4 cell pack.

Hello Tony,

Can you take a GG file from the good pack and the problem pack and send it to me?

I can. we use the same GG file for all packs and then calibrate them. GG_Compair.rar

The pack that had the issue was the SN0291. I grabbed one of the random files and it looks like that one was SN0278. the default file we load is the "default.gg'

to cure the "LCD" shows 5 bars and the voltage on the pack is 12V (about 1/2 dead) I changed no values and charged the pack back up again. That pack is on my desk 3 weeks now and is still full (16.7V) . AKA not showing signs of discharging as it did previously.

Check if any PF flag is set on the registers screen. A screenshot or log will work

adding the SN0278 log in the download was a mistake. that is just making the issue muddy.  Ignore that Gg file. 

the SN0291 IS one that had the Gauge not matching the real charge state after sitting on the shelf

.

This shows the state of 93% RELATIVE state of charge and the battery voltage is 12.880V

Hello Tony,

Thanks for sharing. MaxError is set at 100%, this indicates that the gauge knows it is not gauging correctly. The question is what caused MaxError to increase.

Since there are only 8 cycles, MaxError should not be greater than 8. According to the TRM only a full reset causes MaxError to be 100%.

The most obvious things to check are

1. Solder connections - possible breaks due to expansion/contraction that cause power disconnect

2. Host system commands - Check if the host sends any commands that may be interpreted as soft reset in case of noise ( bit flips)

well, there is no host connected to the batteries. once they are set nothing is communicating with the BQ20Z655. only when one is returned is a cable connection and communication used to discover what is happening.

Hello Tony,

That is strange.

Is the cycle count in your golden image set to 8? Or is this seen after a few cycles?

Verify that IT enable command is sent after cell attach during manufacture. 

The golden image was included in the rear file. the cycle count on that is set to 0.

we do not currently send the IT command after each cell is attached. 

after attaching all 4 cells there is a PF failure because the board is powered when there are empty cells. we clear the PF and send the reset command.  then we do the calibration on the board. fully charge it and do the learn possess. send the IT and reset, discharge then wait, charge then wait, discharge then wait.  

the SN0291 pack is a pack we are using here.  they may be 8 cycles on this pack.  After every use, it is charged and placed on the shelf for subsequent use. it is during this shelf time that it appears then cells are discharging and the BMS does not know about it.  this results in a discharged battery with the LCD gauge still showing 5 bars.  the shelf time period is 2 to 3 months.

I would check the current calibration on the packs with the issue.

In the photo attached to this topic, you can see the current is at -4mA. The CC deadband is set to 20mA. Even in standby mode, the current draw is greater than the 20mA headband when connected to a unit. on the shelf, the dray is as low as can be calibrated.

Hello Tony,

Is there a real current of -4mA flowing?

If there are continuous periods of low current draw, we want to make sure that those are accounted for.

no, the -4mA draw is not real. when connected to a unit the dray is 40mA for 20 minutes then a 4A draw for 4 minutes. The capacity of the pack makes for at least 7 cycles before a recharge is required.   we usually recharge them after use.

If the -4mA is not real, then the gauge calibration is incorrect, right? Otherwise why is it reading -4mA?