This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ35100: EOS Mode - Battery draining test and parameter configuration

Part Number: BQ35100
Other Parts Discussed in Thread: BQSTUDIO

I read through the application note: How to Configure the BQ35100 for EOS Mode and have a few queries for which I will need your valuable inputs:

  1. If the battery that I intend to use in my final application is already in the bqSTUDIO library, do I still need to perform the full discharge test of the battery as described in the application note? If yes, what benefit does it bring?
  2. How often does the battery draining test need to be carried out? Is it once per production batch?
  3. After reading posts related to BQ35100 on the forum, I understand that if EOS alert is the only expectation and no SOH level reporting is needed, then a Chem ID does not need to be programmed into the chip. Is my understanding correct? In that case, is the full discharge of the battery as outlined in query no. 1 needed?
  4. The application note talks about saving the scaled resistance and measured impedance on a Non-Volatile storage attached to the MCU. Since scaled resistance is generated from measured impedance based on the Chem ID, I believe that the example assumes that a Chem ID is already programmed into the chip. Is my understanding correct? The application note does not mention this step or requirement.
  5. Section 7 of the application note outlines the procedure to configure the EOS parameters. The recommendation about the parameter New Batt R Scale Delay needed for initial EOS learning is clear. However, I have questions about the parameter EOS Trend Detection. Won't a value of 20% be enough to determine the EOS event or does the value need to be determined based on when the battery becomes unusable based on individual circumstances?
  6. Other than the two parameters mentioned in query no.4, are there any other parameters in the Table 7-2 that needs to be set by the MCU?

Regards,

ashare

  • Hello Ashare,

    You would not need to run a characterization yourself if the cell already exists, as mentioned in the TRM in EOS mode SOH may not be very reliable and may not be useable since some cells have a flat resistance curve until near EDV.

    I assume the battery drain test is the procedure to collect the Ra table values from the cell, this only needs to be performed once per battery, if you change batteries you would need to run it again.

    That's correct, if you only want EOS alert functionality in EOS mode (no SOH%) then you do not need to program a chem ID and do not need to do any characterization yourself (unless you want to test the averages and when they will trigger EOS).

    During this step the measured Z and Scaled R should be saved for analysis, you do not need to have the chem ID programmed already since if you are doing this characterization you would be over-writing the chem ID Ra table anyway.

    You can see in figure 6-1 that with a higher trend detection the closer to EDV the gauge will trigger EOS alert, so it is dependent on your application. 20% is safe for most applications since if it is set too low you could get a false trigger with noisy data. 

    The EOS pulse count threshold can also be configured for the application, generally it should be set to about 50% of the total pulses you expect in the lifetime of the battery. 

    Sincerely,

    Wyatt Keller

  • Hi Wyatt,

    Thank you for the prompt and elaborate response. Here are a few more questions related to the topic of EOS alert with reference to the application note in my initial post:

    1. If EOS alert is all that I need, then neither do I need to program a Chem ID, nor do I need the Ra table values from the discharge experiment. Correct?

    2. I assume the battery drain test is the procedure to collect the Ra table values from the cell, this only needs to be performed once per battery, if you change batteries you would need to run it again.

      By changing batteries, I believe, you mean changing to a new battery model with a different capacity or different manufacturer. Correct?

    3.  

      That's correct, if you only want EOS alert functionality in EOS mode (no SOH%) then you do not need to program a chem ID and do not need to do any characterization yourself (unless you want to test the averages and when they will trigger EOS).

      Which averages are you referring to here? Is it the average of the measured impedances from different samples of the same battery type at which EOS is triggered?

    4.  

      During this step the measured Z and Scaled R should be saved for analysis, you do not need to have the chem ID programmed already since if you are doing this characterization you would be over-writing the chem ID Ra table anyway.

      Didn't quite understand this. Scaled R is not generated unless a Chem ID is programmed into the gauge. If Chem ID is already programmed into the gauge, what is the need to extract the Scaled R/measured Z from the gauge and plot?

       

    5. Can you elaborate on what you mean by "...set the resistance filters..." in your recent reply to this forum post?
  • Hello Ashare,

    1. Correct, for only EOS alert you do not need the chem ID or to do any characterization unless you want to refine when the EOS alert is triggered by changing the Trend detection percentage.
    2. Yes that's correct, I mean if you change battery models or manufacturer, not for every battery.
    3. I mean the moving averages used to detect EOS alert, you can adjust the trend detection percentage.
    4. If you are generating the table yourself it would not matter if you have the chem ID uploaded, you can use the measured Z (which is not adjusted by the Ra table) and that would be your Ra table.
    5. I believe this should be corrected, you need to adjust the EOS Trend Detection%, not necessarily the resistance filters themselves.

    Sincerely,

    Wyatt Keller

  • Thanks for answering my previous questions. I have a few follow-up questions.

    1. Can you elaborate on the mathematical relationship between the measured Z, scaled R and Ra values?
    2. The moving average function is implemented internal to the chip. Correct?
    3. If Chem ID is not programmed and I simply use the EOS alert mode based on measured Z, is temperature compensation still applied or is it only applicable to SOH calculations?

    Regards,

    ashare

  • Hello Ashare,

    The Measured Z is the raw measured value from the estimation of the IR drop. Scaled R uses the Ra table and some of the intial Measured Z values to created a scaled resistance which aligns closer to the Ra table.

    Yes the two moving averages are calculated internally.

    Temperature compensation wouldn't be applied to the resistance estimate, we are calculating the raw resistance value and looking for the "hockey stick" type behavior near the end of discharge so temperature fluctuations should not trip the EOS alert.

    Sincerely,

    Wyatt Keller