BQ35100: Estimating battery lifetime in percent in EOS mode

Jamie Yuen

Part Number: BQ35100
Other Parts Discussed in Thread: BQSTUDIO

Hello, I found this post (pasted below) which is almost the exact situation I have, but was disappointed to see there is no solution in the thread - it went private. In my case the SOH is counting down by the max of 2% each time, but that is certainly far from reality as I am using a 19Ah LiSOCl2 cell.

The cell is recovering to the nominal 3.6V between load cycles.

On wake I enable and start the gauge, then my load profile is 40-50mA for up to 2min, then a 125mA pulse for 2s, then down to 10mA while the gauge is stopped, then into low power sleep.

While awake the voltage is drawn down to 3.4 - 3.5V, during pulse its close to 3V. During gauge stop it seems the voltage recovers to about 3.5V, but doesn't get back to 3.6V until the system is sleeping.

Do I need to put the system in low power sleep during the gauge stop period to ensure the battery fully recovers? I will try this and report back. It wasn't clear to me on the datasheet the proper procedure.

To make sure I am configuring the gauge correctly, here are the steps I am doing:

Calibrate Voltage & Temp offsets, CC gain & delta. The board and CC offsets seem ok for my device.
Write design capacity, design voltage, terminate voltage, cell count, max load
Set EOS mode
Write EOS trend detection pulse counts to 0
Write EOS SOH smoothing start voltage

Is there any other config I am missing?

From the forum It looks like the default ChemID is appropriate for LiSOCl2 chemistry?

Thanks!

In reply to Eric Vos24:

Eric and Alessandro,

thank you both.

I can live with an somehow incorrect SOH if it just counts down from 100% to 0% in a consistent way until EOS is reached. Regarding passivation effects we are able to provide a constant discharge pulse. With this constraints, is it necessary to get an own TI Chem ID? If yes, what must I do to get one?

In the meantime I implemented BQ35100 on my PCB and made some tests. The BQ35100 is calibrated as prescribed in the docs with the help of Battery Management Studio. In my system when issuing a BATTERY_NEW command, SOH reads 100%. Perfect! But thereafter, the SOH counts down by 1% after each measurement which definitely does not reflect the reality. I think, there is something misconfigured. What can I do to debug this issue? Or maybe I just do something wrong when starting a new battery? What do I have to do to initialize a new battery correctly?

Thank you again!

Regards,
Oliver

over 7 years ago

0 Vos over 7 years ago

TI__Genius 10370 points

Jamie,

I am sorry the other post went private and i will answer you here for others to see as well.

Let me first say the SOH value in EOS mode is not ideal. We use the measured impedance on each pulse once a gauge stop command is received and compare that against the ChemID programmed into the gauge. The problem here is that for these cells the impedance is very flat until we start to get to the end of the life so any slight increase could mean large jumps in SOH estimation. It is not uncommon for the SOH to decrease rapidly and then stay at a lower SOH for a long time until the cell truly reaches that state. With that being said it is important that you are selecting the True ChemID for the cell. While the default ChemID should give consistent results they might not be the best. I would say that if your cell is not listed please let me know and i will get you the correct way to request a ChemID be created for your cell.

Moving on here is a breakdown on steps to help debug how SOH is calculated in EOS mode

1) Are you able to get good MeasuredZ results? From your post The ideal situation would be to wake the gauge prior to the 40-50mAh load, send gauge start, perform the 40/50 load, perform the 125 load, issue gauge stop, then wait for the results prior to shutting the gauge down. This will ensure you take a well rested OCV at the prior to the pulses and you get good IR drop during. If you are able to swap the 125 and the 40-50 i would say to gauge the 125 solo then after the gauge completes perform the 40-50, but i assume the 40-50 is the measurement which is needed first and the 125 is the broadcast. Just before you issue the gauge stop command you want to return the system to the lowest power state possible for the "R Data Seconds" to get the best measurement. If you cannot go to 0 it should be ok, it must be far less than the pulse amplitude.

2) Compare the MeasuredZ against the Ra table and see which grid it falls to. The grid are not evenly spaced and the first 7 are about 11% apart. meaning the Ra0 is full and Ra1 is about 89%. This will tell you where the raw measurement is and around where SOH wants to report. It isn't perfect because the gauge also does temperature compensation and other TI proprietary things, but it is a good ball park.

3) Once you get to "New Batt R Scale Delay" Pulse count the gauge will take the measuredZ and compare that against Ra0 and produce an RaScale factor. This is to account for cell to cell variation and different levels of cell passivation. From then on the new ScaledR value will be used to calculate SOH. It is important to note until the scale is learned the unscaled measuredZ is used to update SOH.

4) EOS detection is truly where the power of this gauge lies. It runs at the same time, but is a separate algorithm. It has two filters that are of different lengths. the measuredZ and ScaledR (when available) are fed into to keep a running slope. since the filers have different lengths as your impedance increases the slope of the two filters will change and once the filters reach a threshold EOS will trip.

5) A pulse counter is kept for every GaugeStart/GaugeStop sequence. This is so you will not even look for EOS until a pulse count threshold is met and when to take the new battery scale factor.

Hopefully this sheds more light on the gauge and address your questions. Please feel free to follow up with any further questions and i will try to keep the post public for others to see.

Thanks,

Eric Vos

0 Jamie Yuen over 7 years ago in reply to Vos

Prodigy 80 points

Thank you Eric, this is extremely helpful!

I am using the Omnicel ER34615, which is the same as an EVE ER34615. I didn't see these listed in the ChemID in bqstudio. I think it's pretty standard chemistry though.
No problem with the SOH being off as you describe, but right now for me it is just decreasing straight to zero. I'll dig into your suggestions.

I need to check Z values, will report back. Currently I am waking and starting the gauge prior to the 40/50 and 125mA load, then going down to 10mA and issuing gauge stop. I did notice the voltage does not recover completely during gauge stop. Correct the 125mA is data transmission.

Thanks,
Jamie

0 Vos over 7 years ago in reply to Jamie Yuen

TI__Genius 10370 points

Jamie,

I forgot one critical thing. There is one minor issue with the current gauge that will be fixed whenever a new revision is released (not sure when that will be). Please set your terminate voltage to 900mV.

Note this is not an issue when using the default chemID in the device.

Thanks,
Eric Vos

0 Jamie Yuen over 7 years ago in reply to Vos

Prodigy 80 points

Hi Eric,

Ok thanks - I'm justing using the default ChemID for now but will keep that in mind.

I took a look at the Z measurements - that indeed seems to be the issue.
My measuredZ starts at 2968 and was down to 2964 after running for a few hours, at 4 transmissions per hour. I guess that falls at the bottom of the Ra table, which explains why the SOH just drops right down?

Any ideas where to start debugging the Z measurements?

Thanks,
Jamie

Power management

Power management forum

BQ35100: Estimating battery lifetime in percent in EOS mode