• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 65 subscribers
  • Views 1149 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Estimating battery lifetime in percent in EOS mode

Oliver Birnfeld
Prodigy 95 points
Part Number: BQ35100

Hi,

we are using the BQ35100 in EOS mode with 3 Saft LS14500 LiSOCl2 cells in parallel. We are able to provide a discharge pulse on regular basis e.g every 24 hours. 

Is this the correct configuration to get an estimation of the battery lifetime in percent? If not, what do we have to do to let BQ35100 count down from 100% to 0%? Is this even possible with this type of battery?

Thanks and regards,
Oliver

  • 0
    TI__Genius 10370 points

    Oliver,

    Yes the bq35100 is the gauge to use for the LiSOCl2 type cells and yes the EOS mode is also the correct mode. In EOS mode there are two algorithms running simultaneously.

    The first is EOS detection, this mode uses two long term filters to establish when the knee of the impedance profile has been reached indicating when the cell is truly about to be dead. This is the main purpose of the EOS mode.

    The second algorithm is EOS SOH (state of health) calculation. This revolves around an impedance correlation methodology to establish an SOH over the life against our IT chem ID for the cell. This will report a value of 100-0 decreasing by a maximum SOH delta each gauging cycle. 

    The bq35100 does require some host interaction thought. It would require the host to enable the CE pin to turn the gauge on, send the gauge start I2C command right before the pulse is about to be applied, apply the pulse load (minimum 100mV battery IR drop required),  send the gauge stop I2C command, read desired information from gauge, then drive CE low to power the bq35100 off again. The real benefit to this part is that it remains off for the majority of the time in order to save power.

    If you have other questions please let me know

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 95 points
    Eric,

    thank you very much for your fast and detailed answer. I already implemented the EOS mode as describes and it works very well.

    There is one point left that irritates me a little bit. So far, I'm using the default algorithm. You are mentioning a "TI chem ID" and in another thread (e2e.ti.com/.../665613) someone stated, that "...if you are using the default chem id for the SOH while in EOS mode then you will have to ignore the SOH reading."

    What chem ID must I use to have SOH calculated right?

    Thanks and regards,
    Oliver
  • 0 in reply to Oliver Birnfeld
    Prodigy 75 points

    Hi Oliver,

    it's been a while since I work on this component, I have a SAFT LS17500 and from what i understood, for our type of battery the default chem ID is the correct one.

    My bq35100 is in EOS mode, but I never ucceeded in the reading of the SOH. The problem is that the estimation of the impedance and then the SOH is very related to the type of load, for example with a current pulse generated by an electronic load the measured impedance is about 1100 mohm, instead with a pulse of the same duration and amplitude but generated by a RF transceiver, the measured impedance is about 2000mohm. This lead to a different reading of SOH; at 1100mohm the battery is considered almost full, but at 2000mohm the battery is considered empty.

    Please let me know If you'll succeed.

  • 0 in reply to Alessandro Berruti
    TI__Genius 10370 points

    Thank you Alessandro!

    Oliver,

    Let me clarify any inconsistencies. For SOH in EOS Mode a TI Chem ID needs to be created for your battery. The default Chem ID is a mix SAFT LS17500 (EOS Mode) and a different cell for SOH mode (i need to get the model number) as Alessandro stated. 

    This gauge revolves around consistency. We calculate the impedance of the cell on what we call the learning pulse and compare it against our full charge state iof the stored chem ID. From those two value we generate a scale factor which will be applied to the rest of the life. This new scaled impedance value is used to compare against our ChemID table and determine and SOH. Due to things like cell to cell variation or number of cell in parallel this scale factor is needed. Even with these factor our testing have shown the same general shape of the impedance is the same over the life of the cell. It is true if you vary the load you will get a different impedance value. This is because LiSOCl2 cells regenerate a passivization level which affects the impedance. The higher the load the larger your impedance will read because more passivization will bleed off. This is why it is important you gauge the same type of pulse (amplitude and rest between pulses). 

    Let me say the main purpose of EOS mode is the EOS detection. SOH is an added feature, but not the golden bullet.  cells also have an impedance hump around 60-40% which might cause SOH to deteriorate faster then hold steady for a while while the True SOH catches back up. by default we do not allow SOH to increase fro any reason for user experience.  

    Please let me know any other questions you might have. 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 95 points

    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

  • 0 in reply to Oliver Birnfeld
    TI__Genius 10370 points

    Oliver,

    I will start a private thread to debug with you.

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 95 points
    Thanks Eric!