BQ27Z561: Sudden drop in RC and RSOC

Please disable IT Gauging Ext, DSG_0_SMOOTH_OK (bit 0. change IT Gauging Ext from 0x003F to 0x003E). It looks like smoothing to 0 was triggered (e.g. a short voltage glitch down to 2700mV + 150mV, not logged due to the interval). True RM is not zero, hence this is not about a capacity simulation but due to smoothing.

Ok, I will try that. Thanks for the quick reply.

One more question related to BQ27z561, will it report me correct RC and RSOC if i connect unbalanced cells (I am using 2 batteries in parallel connection where Bat-1 = 2.5V, Bat-2 = 3V)?

Thanks,

Parth

In a parallel configuration, the cells will inherently balance out (because they will be forced to the same cell voltage so if each open cell voltage is different, there will be a direct current between both cells that eluded the gauge. The gauge sees the resulting common cell voltage and uses this for its RM and RSOC calculations (which is correct for the combined battery).

I performed full discharge cycle after disabling DSG_0_SMOOTH_OK bit as you suggested and everything is working fine in BQ27z561 EVM.

So i generated golden image with this setting and tried to perform full discharge cycle in our custom board but i am not getting proper RSOC. Whenever i reboot the system, RSOC is getting back to 100% regardless of whatever battery voltage is there (suppose i am rebooting my board at 70% RSOC and when board gets powered up it's getting to 100% again, I don't understand the reason why that is happening).

Here i am attaching an excel sheet of that cycle. ( File Name - sensor_voltage_pecentage (1).xlsx)

2728.sensor_voltage_pecentage (1).xlsx

I also performed another full discharge test, in that test i observed two same issues.

1 - RSOC was 100% at the starting of the test even though batteries were not fully charged.

2 - Sudden drop in RSOC ( From 74% to 0%).

Here i am sending you that file also for analysis. ( File Name - ToF_BAT_Dischg_Data_23Aug.txt)

ToF_BAT_Dischg_Data_23Aug.txt

Also sharing data memory gg.csv file and schematic snap of my board for analysis.

bq27z561_datamemory.gg.csv

Can you please help me to identify why everything working fine in EVM board but not in my custom board.

Thanks,

Parth

Are you power cycling the gauge or resetting the gauge in your driver when you boot up your system? If so, please change this if possible. The gauge is supposed to always be powered up and monitoring the cell. It's not supposed to be power cycled or reset as this will not allow the gauge to reliably measure cell state.

No, I am not resetting the gauge ever.

I am directly reading all parameters over I2C commands. Although i am getting these issues.

Thanks,
Parth

What happens with the gauge when you reboot your system? The gauge won't just change SOC unless something significant happens. From 70% to 100%, it would have to be forced to take an OCV measurement where OCV changes significantly (or it's not a true OCV). The gauge won't just do this on its own but it will have to get instructions from the host uC (for example, a reset).

Please make sure that your host uC doesn't talk to the gauge at all during system re-boot.

I rechecked everything in host controller firmware, there is no communication with gauge at all during reboot. Although I'm getting these issues. 

Please tell me if i should look into anything else? 

Maybe on schematic design! 

Thanks, 

Parth

There has to be a trigger that causes the results to change. The gauge doesn't know that your system reboots so if the gauging results change after a system reboot, then *something* must have happened between the gauge and the host uC. I can't say what this is as I don't know your system but I can say that this is a common issue that the driver restarts or resets the gauge when the system reboots and this will often lead to significant changes in SOC due to the fact that the gauge cannot determine initial cell state if the cell isn't 100% relaxed.