BQ35100: EOS accurate detection validation

Fran,

Sorry for the delay. I have been accumulating the answers for you and will be ready to post tomorrow or Friday.

Thanks,

Eric Vos

Hi TI members,

I received an Email saying that the problem was solved by your side but I haven´t seen any update or answer from your team yet. My problem is not yet solved and I Still waiting for an answer.

HI Mr. Vos,

Thanks for your answer. It was really useful to have all these answers. However, from your statements, some other questions come into play:

1)  On your answer you said: "The short filter by default is 50 deep while the long filter is 200 deep". However, even on the TRM, it says that the Short and long-term filter default values are 251 and 253 respectively. Why then are set to very similar values when in your answer you stated they are quite different among them?. shall I adjust them to a 50-200 value?

9) About the Ra table: Is this a scaled table in which every point corresponds to a certain typical SOH %? (For instance, Ra0 corresponds to a 100% SOH, and R1 to a 94%, and so on). How different is considered to be "vastly difference"? 

Still, related to 9: How can we get rid of the SOH_MERIT error? Or at least, can you tell me what are the top 5 main causes of this? I have read a post like this one: and it seems quite complex.  

and about to 10) How can we build our own Ra table? is it updated by the BQ35100 at a certain point?  For our system, we are using SAFT LS14500 cells


With these questions answered, I think our inquiry would be solved by this moment. 

Hi Mr. Vos,

I am still waiting for your answers to the questions related to your answers. Do you have any update?

The Ra0 column has 15 numbers. the  above are 14. can you please explain that? plot(x=[0:13], Ra[0:14]) ?

Vos said:

The short filter by default is 50 deep while the long filter is 200 deep

and

Vos said:

For the threshold you want to set it so the pulse count is around 50% of the application expected pulses. It makes the EOS detection not looked for until this pulse counter is reached.

This is extremely useful information, that  I do not recall seeing elsewhere. the default here is 120 counts. so does the rolling average start comparing for EOS at 120 before the 200 is reached? or does it start when 200 is reached  for the default of 120?

the techref says you could set count to minimum 1, but clearly that would be a problem...

Hi Mr. Vos. 

At this moment most of my inquiries were answer except the SOH Merit issue. Also another question seemed from 10):

If I am taking measurements to obtain a new Ra table, what should I do about the Chem-ID? Shall I use any Ra table while taking this new measurement or shall I use the default? Is there a particular post which illustrates this procedure in detail? 

With these two issues solved, I will consider the issue solved.
Thank you

Hi Mr. Vos.

The system closed my case on the Customer service system from TI. I cannot continue talking on the Customer Service system because now they closed the case even though I said clearly it is not until you provide the answer to the last 2 questions (or at least give an answer for the SOH_MERIT problem). I am still waiting for Mr. Vos answer to the last 2 inquiries unclear. After that, I will consider the case closed. I will try to contact TI customer service again to reopen the case because the SOH_MERIT had no clear answer or solution around the forum and it is a problem I am having right now. 

best regards,

Fran,

1) For the Ra table you will use the MeasuredZ value to update your values to. Please use the correct chemID you plan to use in production. 

2) SOH_MERRIT: I am currently getting a FW resource to help describe the condition this is set. i will post the answer once i have it. It will be this week. 

Thanks,

Eric Vos

1) Ok. To see if I understand: I will take impedance measurements step by step and then I will use the MeasuredZ and I will replace the values on my own Ra table (For instance, Ra0=MeasuredZ at 0% discharge, Ra1=MeasuredZ at 11% discharge, and so on). Is that correct? And about the Chem ID, It is always loaded to the BQ35100 (for the saft LS14500). Is all of this correct? 

2) Ok. I will consider this solved when you publish the solution for this problem and I will not bother you with this.

If the 1) is correct, we could be finished. 

Thanks for your effort. 

HI Mr Vos,

Now only 2) remains to be resolved:

2) What do you mean with R/C values? How much time shall I provide between GE_high, Gauge_Start, and the pulse? I provide the command and the pulse manually. Can you give me a step-by-step guide about how this solution should be applied? (how to prevent this error to appear) since I have tried everything and nothing works and I don´t understand your solution. If the error disappears, I will be done with this issue.

If you have the SOH_MERIT FW resource you mentioned, please post the solution here. It would be great because there is no one solving this problem in the whole forum :( 

Once again thank you, but this topic of SOH_MERIT is crucial for me to get solved. All the other inquiries were solved but this one was the most persistent. 

Fran,

Solving for the R/C in an internal algorithm proprietary to TI. A battery can be modeled as an RC circuit so we are trying to back calculate these values from the voltage/current sampling we are doing. 

The proper flow should be. GE_HIgh --> Poll for the [INIT] bit to set --> Send Gauge start --> Wait 1 second --> Apply pulse --> wait 1 sec --> gauge Stop command --> wait got G_Done bit. The 1 second might be able to be reduced through testing. 

This needs to be done when the battery is relaxed and is no longer increasing due to the load removal of the previous cycle.

Thanks,

Eric Vos

HI Mr. Vos

I am using the Evaluation board to this extend. I have just a resistor which I manually connect to provide a load to the system and I also send commands through BQstudio. Basically, I follow these steps:

1. Connect the battery gauge, providing the GE high (with BQstudio running)
2. Wait until the OCV is measured and INITCOMP=1. I make sure the battery is rested after waiting around 5 hours after any previous discharge and by monitoring voltage with the help of a voltmeter to make sure the voltage is not fluctuating. I also make sure the OCV read by the gauge matches or is lower than the voltage measured by the voltmeter.
3. Send the Gauge_start command, wait for 1 second and connect the resistors to send the pulse (I put a "hooking wire" on one side, so I can connect the resistors easily). Then I wait for 30s
4. Disconnect the load, wait a second and send the Gauge_stop command
5. Wait until [G_DONE]=1. and let the magic happen

I repeated this twice (when I read your message at night and this morning), and still, I have the SOH_MERIT error. What could happen this time? 

Fran,

The discharge of 30Sec is very long for the expected application. Please reduce this load duration down to 1-2 seconds to see if that helps 

Thanks,

Eric Vos

Hi Mr. Vos,

I tried in that way and it didn´t work. Then Ideally how long should be that pulse? because in our application, we are using a series of pulses that happens for 1 to 5 minutes, and if using a set of pulses is not a good idea, then we should truncate the measurement to use a particular pulse and use it for measurement.

It is odd that everyone who had this problem on the forums hadn´t found a solution for this problem.

Hi Mr. Vos.

As I mentioned, the proposed method was not effective. This issue is still unsolved. 

I asked also if a pulse that lasts 2 minutes would be fine and you answered that it is totally fine but now you suggest me use a 1 or 2 seconds long pulse. Why did you say before that using a 2 min long pulse would be fine? 

On the other hand, the gauge in our real application, the device activates once per day to take measurements and transmit the data to a cloud system. Also uses a supercap. This cycle lasts between 5 to 7 minutes in total. Unfortunately, I cannot show the profile due to company secrecy. Is this okay to activate the gauge for measurements during an activation cycle where several pulses occur for around 6 min? 

Fran,

Either pulse duration should be fine. I was commenting that the original design of this part had a pulse length of seconds in mind. I wanted you to test with 1-2 seconds to see if it resolved the issue. 

Do you have a super cap on the system now?

When you apply the load how much of an IR drop are you seeing in the battery voltage?  

Thanks,

Eric Vos

Hi Mr. Vos
Ok. In the system, there is a supercapacitor that is charged before and in the middle of the cycle. Fortunately, during the discharge, it gets drops over 100mV. The nominal voltage is 7.3V and it drops during the discharge up to 6.9V. The supercap is not affecting the voltage drop.

Hi Mr. Vos,

I have some updates for you:

Firstly, No matter how long I make the pulse (1-2 seconds, shorter or longer), I get the MERIT error. I always make sure by the help of a voltmeter that the OCV from the battery is the same or lower than the OCV measured by the gauge (the first voltage measurement the gauge makes when GA is set to high). I have an honest question for you: 

Has this problem got solved from a previous post?  Because at this moment it has been impossible to get rid of this...

About the Ra table:

As specified: I measured the impedance and also both averages to determine how well the device is able to detect the EOS condition.

In this case, the SOH was quite inaccurate. I will show you some plots to demonstrate this:

Basically, the SOH was similar to the trend of the impedance but it was always offset. The EOS was detected when the battery marked 22%.

This is the plot for the impedance and EOS Trent averages:

The ChemID was from SAFT LS14500, the Ra Table I used was this: 

This is the plot from both averages (With my predicted SOH):

The EOS was successfully detected as predicted since the warning was given when voltage started dropping and my calculated SOH was around 7 to 10%, and the difference among them was around 20%.

Right now I got the following Ra table and its comparison to the previous one (The new Ra table corresponds to MeasuredZ). What I did was just averaging the impedance value every 10 measurements on every step:

I got problems by inserting Ra14 because BQstudio says the number is out of range, but since is the last step, I think any high number would fit there as well. 

I am repeating the test, but now, I am using the new Ra table to see if the SOH gets any improvement. However, it just counts down every time I send the start/stop commands. The only change I did was just adding the new values to the Ra Table through BQstudio. What do you think about the values, and why previously was not behaving like that?

In every instance, the SOH_MERIT was present. This problem still unsolved. 

Hi Mr. Vos

Have you checked already the current results? Is there something we can do now to improve the SOH measurements and ripout the SOH_MERIT error? 

Fran,

Are you able to capture a scope plot of the battery voltage and current during the window the gauge is active? I do not know why SOH_MERRIT is on at this point.

Thanks,

Eric Vos

Hi Mr. Vos,

This is an example of how I am taking measurements.

I Take 1 min 44 seconds long pulse for this purpose (don´t trust the timeline). Also, I make sure the battery OCV measured on the voltmeter would not overpass the OCV measured on the gauge.

Also, what do you think about the Ra table obtained? 

Fran,

Thank you for the pulse, I have feed the pulse shape back to my algorithm team to see if they can help determine why SOH_MERRIT is being set. I will hopefully have more information for you later this week.

Please provide the RAW log file for how you did the Ra calculation. I will need to check your values. it seems off to me that the values decrease so much near the mid-end. 

Thanks,

Eric Vos

HI Mr. Vos.

In this document, I have compiled all the data collected, and also all my calculations concerning the Ra table calculation.

MEAS FINAL1.xlsx

NOTE: See the sheets: "Ra Measurements" (Where I calculated the pulse width, SOH approximated and the OCV determined per measurement)  and "Data collected" (Data resulting after the measurements). 

Fran,

Thank you I am taking a look and will work with an algorithm team member to see if we can figure out the issue with SOH_MERRIT. I hope to get back to you by Mid-next week

Thanks,

Eric Vos

Hi Mr. Vos

I am expecting your answer to continue my research on this topic. Until now, my goal is to obtain an Ra table that fits better our profile. Right now I am doing a test by using the board to obtain values of impedance "In board" to adecuate the Ra table to that particular case. 

In this post: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/913877/bq35100-eos-measurement-health-steps-down-in-2-steps-to-0-and-li-socl2-still-not-empty/3407821?tisearch=e2e-sitesearch&keymatch=BQ35100%25252525252520SOH#3407821 Mr. Wyat Keller suggested to use GPCCHEM to find a more suitable Ra table according to my profile. Shall I investigate about it? 

Fran,

No you cannot use GPCRB tool for primary type chemistries. I am still working to understand why you are getting SOH_MERRIT

Thanks,

Eric Vos

Fran,

I spoke with one of our algorithm experts on this case. The algorithm was 100% designed to work with short pulses around the 1 sec timeframe. If a longer pulse is needed you might need to extend the EOSData.Values.R Data Seconds to a value of 8-10 times the length of the discharge duration. SOHMerit being a measure of numerical stability, may still not work out due to all math losing resolution with so many samples being taken.

Overall the best solution would be to install a "learning load resistor" that the host can enable for 1second independent of the application load

Can you try to extend the RData seconds to see if it improved the SOHMerrit flag?

Thanks,

Eric Vos

Hi Mr. Vos.
I will try to do this soon.

Have you looked at the Ra table obtained? does it make sense to you?

I was thinking that I should repeat the discharge test and take more measurements to tune it as best as possible. What do you think? 

spot the difference?

Vos said:

he algorithm was 100% designed to work with short pulses around the 1 sec timeframe. If a longer pulse is needed you might need to extend the EOSData.Values.R Data Seconds to a value of 8-10 times the length of the discharge duration. SOHMerit being a measure of numerical stability, may still not work out

marketing, datasheet said

"The BQ35100 Battery Fuel Gauge and End-Of-
Service Monitor provides highly configurable fuel
gauging for non-rechargeable (primary) lithium
batteries without requiring a forced discharge of the
battery. Built so that optimization is not necessary to
achieve accurate gauging"

Fran,

Since you are getting the SOHMerit flag still we cannot trust the value from the measuredZ reported. I see you have the data from the Average voltage of the pulse, but do you have the Raw data for each pulse like you provided in the image? Once we get the SOHMerit to not trigger we can use the gauge calculated values. 

Thanks,

Eric Vos

Brad,

EOS mode of the bq35100 is not designed to report an accurate SOH as its primary objective. SOH is an estimation and a by-product of having the measured impedance correlated to a chemID. The EOS mode is designed to produce an EOS alert to know when the battery is near the end of life. The EOS alert does not need the modification to the Ra table being discussed in this thread. Even with a perfect ChemID match the impedance profile could be so flat that a good SOH estimation is not possible until the ending 20%. Due to the shape of the expected curve SOH accuracy should increase as you get near the end though. 

In regards to the pulse duration. This gauge's use case is for high amplitude short pulses, mainly for a radio transmission application. Under these circumstances a "learning load" is not needed. However adding a very controlled load to the system could only improve performance if the application can handle in increase power loss. The pulse in an application can also be too short. the gauge samples voltage and current every 8mSec when active. An 8mSec conversion is rather noisy so you will want at least a few samples to average out. 

Thanks,

Eric Vos

I'm not trying to measure SOH.
However, you've written measuredZ and hence EOS isn't ok with SOH_ERROR and hence Wyatt wrote 
"SOH_MERIT should be labelled as EOS_MERIT because it looks at correlations with the resistance values calculated"

effectively TI are now telling us the chip was concurrently designed to:
1) measure a radio pulse ~ 1s (only) and
2) turn on after 5 hours sleep with a fully relaxed battery

so the marketing that this can be used in any system easily, seems to struggle unless that system sleeps a lot and then does almost no work other than transmit when it first wakes up.
I really am trying to help TI realise why customers/prospective customers keep coming to the forum with the same fundamental issues. Its cost us a lot 

Apologies Fr4n if this doesnt help your immediate need in this thread. 
here's a whole lot of work, showing a battery system trying to simulate years into weeks and failing to trigger EOS with default parameters. (blue is measuredZ, green EOS alert 0) and the other 2 the long and short term averages not trending far enough apart)

Hi Mr. Vos

I have all the raw data obtained through every measurement. I took around 10 samples per step of 5%, making 20 samples every 11% (counting the samples as part of the measurements). Do you need all the raw collected data?

On the other hand, Since the problem is with the SOH_MERIT, and as you said several times that this will not prevent me from getting EOS detection, how can the MeasuredZ reported being affected by this error? I would agree if we talk about Scaled R, but I don´t see a correlation of the quality of the measuredZ values to the SOH_MERIT problem since as you pointed out, the problem might be that the device requires more than 15 seconds to calculate the data obtained.

Would you like to inspect the raw data obtained for certain measurements? I still have every single sample logged. What would be useful for you to inspect? 

Thanks for the support at the moment. I will try to figure out if the EOS_MERIT error goes away.

Hi Mr. Vos.

As suggested, I extended the "R data seconds" parameter from 15 to 60, 120 and 180 seconds and also even 10 minutes, and only sending a 1s pulse (sometimes even shorter), which basically, I just connect the two wires from the load resistors by hand and just "touch" both wires together (of course, after sending the START and before STOP commands). I have tried several times today and the SOH_MERIT error persists. This time, I am using just a single cell with a new evaluation board. 

I just wonder why there are several people around with this problem and until today nobody in the whole forum got a solution. 

Attached to this, there is the whole raw data obtained during my whole impedance tracking. on the folder LOG, you will find an excel document that compiles all the values into an excel sheet. Ra table 1 SAFT.zip

I will just sum up my method: 
I have a single cell battery connected to a voltmeter and in series with an amperemeter. To connect it i just put the wires together. 
- Connect the power, observe the INITCOMP bit on, to be sure the device is ready. 
- Make sure the OCV voltage measured is equal, or higher than the value measured through a voltmeter connected to the battery terminals to prevent negative values of resistance.
- Send the START_GAUGE command. Immediately, connect the load and provide a discharge of 50mA for only 1 second (maybe 2). 
- remove the load and send immediately the STOP_GAUGE command.
Wait the amount of time set in R data seconds until I see the results. After giving the values and see the G_DONE bit on high, then I finish turning off the gauge.

As you may see, my procedure is very straight forward and I don´t get any other error except SOH_MERIT.

At this point, I don´t know what else to do.

Brad,

This data looks exactly like I would expect to see. Where the test cutoff is right when you are reaching the exponential growth of the curve. The default parameter is 20% delta between the two trend lines. Based on the image it seems like you are already close and it is only a few more readings away. If you want it to trip quicker you can reduce the 20% to a lower value.

Thanks,

Eric Vos

Fran,

Thank you for this data it will take me a minute to process it all, but I will try to do so over the weekend. 

Thanks,

Eric Vos

Hi Mr. Vos,

Have you any update? I am still waiting for your answer.

Fran,

I have been trying to replicate this on the bench and have been unsuccessful. I would like to take this issue off the forum with you and possibly look at getting your setup sent to me in order to debug further. Would this be an option. 

As a test from our design and FW team can you try the following in parallel. Please record the pulse you apply with a scope so we can use it later for investigation

1) Change to ChemID 632 and run a single 1 sec pulse on a well rested battery

2) Apply a higher amplitude load 

Thanks,

Eric Vos

HI Mr. Vos

Yes, if you consider being necessary, we can talk about it in a closer way.

I will try to give a higher current pulse (close to 80mA) and record it with the BQ and also externally. 

Hi Mr. Vos,

I have already written to you on private messaging. Any piece of news?

I hope everything is going well.

Best regards,

Fran

This thread has gone private to debug further. Currently the suspicion is the hardware setup with lengthy wires. I will post a separate thread one we resolve the issue for others following will have conclusion.