BQ35100: EOS measurement health steps down in 2% steps to 0% and Li-SOCl2 still not empty

Hello Rene,

Can you provide the log file of this occurring and the .gg so we can take a closer look?

Sincerely,

Wyatt Keller

Hello Wyatt,

The communication with the BQ35100 is currently in firmware (done in C) on a STM32.

Next week I will try to reproduce the situation using Bqstudio. As far as I know Bqstudio does not provide some kind of scripting, so I will have to perform the command manually, control the GE jumper manually and watch the timing closely.

I will get back to you.

Regards,

Rene

Hello Wyatt,

For the ease of measurement using bqStudio I changed the 'State of Health Max Delta' to 10%. I started the Scan mode and Started a Log. I have tried to follow the following procedure:

• Connect GE jumper to enable the device
• Wait some time (an ALERT was signaled)
• GAUGE_START and wait for GA
• counted till 10. (BTW no load applied)
• GAUSE_STOP and wait about 15 seconds until an ALERT was signaled with G_DONE
• Removed the GE jumper

The SOH counts down in steps of 10% to 0%.

Regards,

Rene

3364.bq35100.gg.csv

Hello Rene,

Since you are waking the firmware up every minute the gauge is not able rest long enough to let the batteries settle and take the correct OCV reading. Make sure you have a long enough rest between active periods to get correct OCV and measured Z values.

Also It looks like from your log file that your load isn't high enough to cause a 100mV drop from OCV, this allows the gauge to take the measurements needed for its calculations to be accurate.

Sincerely,

Wyatt Keller

Hello Wyatt,

Okay, but how to resolve this and where and how should I change the firmware to let the gauge take valid measurements?

The following is the current and voltage measured by a Joulescope JS110, which is placed in between the battery and the BQ35100EVM. The load is high enough to let the voltage drop more than 100mV.

What is wrong with the timing here? How long should the time between GE=high and GAUGE_START be? Or the time between GAUGE_STOP, the read of the Gauge values (Voltage, Temperature, SOH) and GE=low?

Which BQ35100 register should I read to know it has taken correct OCV and Z value measurements?

And what is the minimum cycle time in which the sensor readout and RF transmit should be performed to let the BQ35100 take a valid measurement? One minute is too short, but what should it be?

Do I understand it correctly: To relax the current state of the BQ35100 it should be connected to the battery, with no load, and  with GE=low for at least 5 hours (according to the BQ5100 Technical Reference Manual section 7.5 'Battery EOS OCV BAD Warning')?

Regards,

Rene

Hello Rene,

You will need to increase the time between activation to allow the gauge to measure the OCV, because it is pulsing so often the gauge us reading negative impedance values.

Yes section 7.5 in the TRM outlines the errors that could happen, you can check this bit to see if there's an error. Looking at your log file the EOS_BAD_OCV bit is set whenever you read negative measured Z values, which is almost every pulse.

There's not a specific time needed because it depends on your batteries, Try increasing the time between intervals until the bad OCV bit is not triggered anymore.

Sincerely,

Wyatt Keller

Hello Wyatt,

I removed the gauge measurement during the power up and initialization state of the firmware. This was the cause for the EOS_BAD_OCV flags and which do not occur anymore.

I have added a 2 second delay between the wake up of the MCU and the GE=high and reduced the amount of activity on the measured voltage around GAUGE_START. And increased the cycle from 1 minute to 5 minutes.

After the GAUGE_STOP and the 15s (R data seconds) not only the voltage, temperature and the SOH is read, but also the Control Status (which indicates a SOH_MERIT) and the Scaled R and Measured Z (see below)

The SOH value still steps down in steps of 10% (since I set 'State of Health Max Delta' to 10%) from 100% (after NEW_BATTERY) to 0%. And it stays at 0%. Still the battery is not empty.

Regards,

Rene

Hello Rene,

Could you try increasing the time between cycles from 5 minutes to 30 minutes or an hour to see if the SOH still drops so quickly? Is there any large capacitance connected with the battery that would be preventing the 100mV drop from the load?

Look through section 8.2.2.6 of the TRM, it explains a little more of the parameters the gauge needs. If you need to transmit very often you may need to leave the gauge on.

Sincerely,

Wyatt Keller

Hello Wyatt,

There are no large capacitors connected. The previously shown image shows there is even more than a 100mV drop (see Jun 17, 2020 7:51 AM).

Section 8.2.2.6 of the datasheet states:

"The BQ35100 device is designed to work in a system where there is a period discharge pulse of at least 10 s of mA for 10 s of ms."

Which is btw a strange sentance with "...at least 10 s of mA for 10 s of ms.". The image of my current and voltage measurements shows the discharge pulse is at about 37mA max but only for 2 seconds. The total GE=high time and the time between GAUGE_START and GAUGE_STOP is however more than 10 seconds.

It also states:

"If the time between pulses needing monitoring is less than a minute, then it is recommended not to power down
the device. However, if the period is greater than 5 hours, then powering down the device between pulses is
expected. Periods in between risk not allowing the battery to rest and any EOS-related data may be
compromised."

So what should be done in case of periods between a minute and 5 hours? Should GE remain high, or can't the BQ35100 be used for these periods in EOS mode?

I expect the SOH value to start at 100% after a NEW_BATTERY. However I'm not using a new battery, but need to know its state of health in this system. So I expect the BQ35100 to perform measurements so the SOH value walks from 100% down to the actual value in steps. The 'State of Health Max Delta' only specifies the largest step it can take to approach the actual value. Is my expectation of the EOS mode operation correct?

Which other parameter should I read from the BQ35100 to determine why it calculates the SOH down to 0%, and doesn't approach a valid value?

Regards,

Rene

BTW. I changed the period now to 30 minutes (with GE=low in between) to measure the difference with the 5 minutes period, and I didn't see any difference.

Hello Rene,

Yes that section is a bit confusing, I think what it was trying to say is there must be a significant load for 100ms to get samples.

Can you try changing the term voltage to 900mV and use a new battery so it can calculate the scaledR? Apparently there is an error in the device and by lowering the term voltage we can bypass the error.

Can you send the chemID and srec file if this does not fix your issue?

Sincerely,

Wyatt Keller

Hello Wyatt,

Within bqStudio I changed the 'Cell Terminate Voltage' to 900mV. And selected Write_All. Now bqStudio reported an invalid value for EOSData R Table Scale. It was 503, so I changed this to -1.

During a new test with a period of 30 minutes the SOH starts at 100% and steps down with steps of 10% to 0%. The ScaledR and MeasuredZ values still behave the same.

The chemID is 0x0615 which corresponds to the EVE ER34615. I use however the Tadiran SL-2780 which ought to be equivalent. The Tadiran battery is not in the list. The Tadiran SL-2780 is btw the name of the battery in Europe, and is the same as the Tadiran TL-5930 outside Europe.

Regards,

Rene

5047.OutputFiles.zip

Hello Rene,

When did the EOS data R table scale get reported as invalid? You shouldn't need to change the scale factor manually, it can effect the gauging. When the new battery command is sent the EOS data R table scale should default to -1, then on the first pulse it initializes the Ra table for the SOH calculations.

The gauge does a look up with the Ra table and compares values to calculate the SOH, you can try increasing the Ra table slightly to see if that helps, because the Ra tables are calculated in good conditions (no resistance on the lines and other application specific factors) you may have to adjust for your application.

Sincerely,

Wyatt Keller

Hello Wyatt,

With a NEW_BATTERY the R table scale seems to be set to -1. After the measurements during which the SOH steps down to 0%, I can use bqStudio to read all settings. The R table scale has changed to a value like 504. When I use bqStudio to write all settings back it complaints this is an illegal value:

Value is beyond maximum value defined for parameter.:EOSData.Values.R Table Scale

So I had to change it to -1 before bqStudio is willing to write the settings.

The Ra table is completely set by the selection of the chemistry. I have now ordered an EVE ER34615 to see if this all is chemistry related.

If so can you add the Tadiran SL-2780 and TL-5930 to the Gas Gauge Chemistry Updater?

Regards,

Rene

Hello Rene,

As long as the scaled are is not -1 after the first pulse, this is when it should be set and used for the Ra table.

You can manually change the Ra table slightly to account for things like wire resistance and other applications specific factors.

I will have to check to see if we can run these batteries, usually the GPCCHEM tool is accurate to find a close match that works well.

Did the chemID upload correctly? can you share the Ra values that are in your table?

Sincerely,

Wyatt Keller

Hello Wyatt,

The Ra Table is still the same as part of the previously uploaded (https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/3364.bq35100.gg.csv). I used chemId 0x0615.

Does Ra 0 correspond to 100% and Ra 14 to 0%? If the MeasuredZ value is used by the BQ35100 to compare this with the values in the Ra Table, I can imagine it will make SOH 0% as the MeasuredZ equals to 5460.

I now also used the EVE ER34615T as the battery (so the one with chemId 0x0615) and started with NEW_BATTERY, performed a measurement every 30 minutes and read the SOH, ScaledR and MeasuredZ ten times. The result is somewhat the same as with the Tadiran SL-2780 but with different values for ScaledR and MeasuredZ.

So the problem doesn't seem to be caused by a different battery only, so what am I doing wrong here?

Regards,

René

Hello Rene,

That's correct about the Ra table, on the first pulse the gauge learns the scaling factor to calculate the scaled R to match the Ra table.

Can you double check the termination voltage to make sure it uploaded correctly? Also temperature can cause some impact, are the tests at room temperature?

Sincerely,

Wyatt Keller

Hello Rene,

You can also manually scale the Ra table as I mentioned before, by scaling the first Ra point to the measuredZ value and then applying that factor to the rest of the Ra table may fix your problem.

Sincerely,

Wyatt Keller

Hello Wyatt,

I placed the battery on top of the bq35100, the termV is a 900mV, and used a previously MeasuredZ value, calculated the factor (which was about 2.1) and scaled the whole Ra Table. So Ra 14 is now about 10000. The end result is again a SOH of 0%.

So there must be something going wrong here. With a ScaledR of about 5300 it should not say SOH=0% when Ra 14 is about 10000.

Maybe some setting (I don't know which) is causing all of this. How can I start with the factory default settings? Is there some kind of reset which does that? Or do you have clean bq.fs and df.fs files which I can use to start from.

Regards,

Rene

Hello Rene,

This is weird behavior, I'll be looking into this and will let you know if I have some updates.

You can send a full reset using the 0x0041 command.

Have you tested this with any other boards or just the EVM?

Sincerely,

Wyatt Keller

Hello Wyatt,

The RESET command 0x0041 doesn't reset or reinitialize the Data Memory to a factory default. The settings remain unchanged in the flash. How to get the factory default settings back? Do you have a df.fs file which can be used to reprogram the Data Memory with the default settings?

I only have used the EVM for all tests.

Currently I'm using a EVE ER34615 and its chemistry settings. I changed the 'State of Health Max Delta' back to 2%, but this doesn't change the problem. The 'Cell Terminate Voltage' set back to 2000mV also didn't have any effect.

Btw, I have not calibrated the BQ35100 since I don't need a high accuracy. Maybe the calibration setting in the Data Flash are incorrect. Could this have any influence on the problem?

Regards,

Rene

Hello Rene,

Currently I don't have an EVM to pull the data from, I would recommend changing the parameters to the defaults in the TRM. Did you try programming the original gg file if you extracted it to the board?

Yes that could cause some errors if the board was not calibrated. I would try calibrating it before testing more.

Could you also post any of the log files you have of the tests? I'd like to double check to make sure the gauge is taking valid updates.

Sincerely,

Wyatt Keller 

Hello Wyatt,

I have used Table 13-1 of the TRM to change all Data Flash values to their defaults. Subsequently I calibrated the Voltage, CC Offset, Board Offset, and Current using bqStudio. Changed the chemistry to the EVE ER34615. Changed the capacity to 19000mAh and selected the EOS mode.

Disconnected the EVM from the EV2400 and connected it to my board and the EVE ER34615 and started the firmware again. This shows again the same behavior. In steps of 2% the SOH is decreased every 30 minutes. Since the battery is new I expect the SOH to be slightly below 100%. But it just decreases in those steps of 2%.

How to debug this?

Regards,

Rene

bq35100_default_cal_eve_er34615_chem_capacity_eos.gg.csv

Hello Rene,

The term voltage must be below 1000mV, I would always set term voltage at 900mV during your tests. The other thing you can do is check the measuredZ and Scaled R and try to adjust the table for your application like we discussed before.

Let me know if setting the term voltage fixes the problem,

Sincerely,

Wyatt Keller

Hello Wyatt,

I changed the term voltage to 900mV, and still the effect remains the same.

I have not changed or tweaked the Ra Table. I have done this before and this did not have any influence. You mentioned the behavior to be weird:

So I have not tested this again.

Next week I will ask the production department to replace the BQ35100 on the EVM. Maybe it is defective.

Or are there any internal registers which I can check to be able to find an explanation to this weird behavior?

Regards,

Rene

Hello Wyatt,

I had the BQ35100 replaced, and so started with a clean set of factory flash settings. I calibrated the Voltage, CC Offset, Board Offset, and Current using bqStudio. Changed the chemistry to the EVE ER34615. Changed the capacity to 19000mAh and selected the EOS mode.

The results and the behavior still remains the same.

How do I get this working?

Regards,

Rene

Rene,

Please retry using the ID 645. There may be an issue with the ID you are using which is causing the rapid decrease in the SOH value. 

Thanks,

Eric Vos

Hello Eric,

I selected the chemistry with ChemID 0x0645 and restarted the firmware. This has a significant effect. With this very different Ra table it now comes to rest at 94%.

So what is wrong with the chemistry of ChemID 0x0615? How do I get the bug free chemistry for the EVE ER34615 (or the Tadiran SL-2780)?

Regards,

Rene

Hello Rene,

I would continue using the 645 ID for now until we can determine the best fix for this issue.

I apologize for the long thread, I didn't realize the ID was bad and could cause this kind of error.

Sincerely,

Wyatt Keller

Hello Wyatt,

The curve in the Ra Table of the 645 ID starts at a low Ra0 value (1568) and rises to a high Ra14 value (32000). The 615 ID however starts at a low Ra0 value (2605) goes even lower at Ra3 (2526) after which it rises to Ra14 (5072). The values are very different though.

When this drop in the curve of the 615 ID is causing the error, this should not only be fixed in the chemistry values of the 615 ID, but also in the firmware of the BQ35100. The calculations done by the BQ35100 should not be influenced by a bumpy curve. Could it be this translation of the ScaledR value to a position on the Ra table curve goes wrong because of this drop?

I used the 615 ID for the EVE ER34615 but also for the Tadiran SL-2780 (TL-5930), as our purchase department marked it as an equivalent (which it probably is not). There is however no ChemID for the SL-2780 (or the TL-5930), but there is one for the TL-4930. The TL-4930 is a LiSOCl2 battery with different specifications compared to the TL-5930. The values of the TL-4930 Ra Table are also different from the 615 ID and also from the 645 ID. This would suggest a different battery type should be accompanied by a different and correct ChemID. So just changing to 645 is not a solution. It does pinpoint to an error but using the BQ35100 we need to know the real End of Service of the used battery and not just a value which is not buggy.

I have also performed the test using the TL-4930 chemistry (ChemId 608) on the EVE ER34615. This Ra Table curve also shows a small drop in the curve. And during the test this SOH percentage also decreases in steps of 2% continuously.

So maybe it is not an error in the chemistry of 615 or 608 but a different problem in the BQ35100.

Regards,

Rene

Hello Rene,

The scale factor should fix the cell to cell variation. When the gauge does the learning pulses the scale factor is calculated because there's always some differences from the chemID.

Also the SOH may not always be accurate in the EOS mode because it's designed more for the SOH mode, you can check some other E2E threads regarding this.

From your testing the SOH was not accurate with the ChemID 645? There are some errors in other older ChemIDs as well.

Sincerely,

Wyatt Keller

Hello Wyatt,

Okay I can understand that the scale factor fixes the cell to cell variations. But the ChemId 645 shows a completely different Ra table compared to 615. So the chemistry of the 645 battery differs from the 615. So how can I use the 645 for a battery with a different chemistry like the EVE ER34615 (ChemId 615) than the battery which is use to get the 645 chemistry? This is not a cell to cell variation within the same battery type group, but the use of a different chemistry for a different battery. If the scale factor would fix the difference between battery ChemID differences, why would selecting a chemistry be needed?

The ChemId 645 doesn't show the error (which ChemId 615 does), but since ChemId 645 has a totally different Ra Table, how can this be accurately used for the EVE ER34615 or the Tadiran SL-2780?

I only have these two batteries available and a low power application which should last for years with such a battery. So I could drain a battery using a higher current and still I will not be able to know if the measured ScaledR of MeasuredZ accurately translates to a valid SOH. I don't have a separate measuring device which can show me the actual and accurate state of health of the battery. For this I use the BQ35100EVM. 

If I would use ChemId 645 will the BQ35100 signal a valid EOS when the battery is actually at 5% when it is used with a EVE ER34615 or a Tadiran SL-2780? Or will the battery be empty already before the BQ35100 would measure this 5%? Or will the BQ35100 measure 5% when it is actually still for example at 60%?

I can imagine the use of the right ChemId is important. The TRM states: "The appropriate Chem ID for the cell to be used in the target application should be used in production." So how do I get an accurate chemistry error free definition for a EVE ER34615 or a Tadiran SL-2780?

Regards,

Rene

Btw, regarding the accuracy of SOH during EOS mode, you mention some other E2E threads. Could you give a link?