• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 380 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ35100EVM-795: EOS: Improving accuracy and measuring uncertainty

Fr4n
Prodigy 50 points
Part Number: BQ35100EVM-795
Other Parts Discussed in Thread: BQ35100

Hi people.

Currently, I am evaluating BQ35100 level of uncertainty to determine the level of gauging uncertainty. At this moment, I am evaluating the EOS mode, and I have performed already a test using a "used" battery, just to determine if the EOS warning is given and to determine how precise is the SOH measurement. I know in the EOS mode, there are two algorithms running: One that determines the SOH based on the measured impedances, and another is the EOS, which uses two moving averages (short and long term) and based on that, determines when the battery is about to be empty. 

This is my procedure:

1) By connecting the 2 batteries in series (Saft LS 14500, 3.6V, 2,6A-h), the GE is on.
2) Send the command Start()
3) Wait 5s and then connect a load (90mA), then wait 1hour 20 min
4)Disconnect the load, then send the Stop() command
5) wait until GE DONE is rise and observe the resulting calculated values

At this moment I have set the following:

I am leaving 2 hours of relaxation to the battery and discharging it for 1hour and 20 min (to try to train as much as possible)

I have set 20 cycles for EOS pulse count detection thrshld

I have set the SOH Delta max to 1%

I am tracking the results based on a calculated consumed capacity vs the SOH measured by the device.

Can you tell if this is the correct way to test the uncertainty level of the fuel gauge for the EOS mode (SOH and EOS)?
Which other elements should I consider to obtain a better result?

  • 0
    Prodigy 50 points

    I have an update:

    I am using the evaluation board and I am using the battery as the power source.The uncertainty was really high because most of the time, the device was marking a SOH of 97% and decreased in steps of 1% up to 93% and then, the battery died. The battery has a previous discharge but I would not expect this level of uncertainty, which basically: "The measurements were absolutely wrong". During my measurements, I just got a couple of cycles where I got EOS_ERR and EOS_MERIT, but not the rest. 

    As I said, I gave 2 hours of rest to the battery, which was sufficient to not raise the flag EOS_BAD_OCV. 

    What could go wrong? Which parameters should I consider to tune in order to improve the accuracy of the Gauge?

    I also tried again with a new pair of fresh new batteries. I set this time:

    EOS detection % = 15
    EOS detection threshold= 16
    LT_EN=1
    V smoothing threshold=4.5V
    Termination voltage: 3.8V (Bellow 3.5V, the system stops working)

    Still after the first measurement, I still getting the EOS_MERIT and the impedance measured and scaled was 9615 mOhm (compared to the Ra table, this is too big). No other odd flag was risen.

    This time, the resting time for the battery is 5 hours and the pulse last 1 hour 30 min. The system gave the EOS_MERIT flag although the battery is brand new.

    I have read from this thread that the cause might be a stressed battery (which was not the case) or a voltage difference in the GE pin before giving the Start() command. I am powering the gauge using the battery itself. Shall I provide energy to the gauge from a power supply?

  • 0 in reply to Fr4n
    TI__Genius 10370 points

    Fran,

    This device is made to gauge lots of very quick measurements (500+) over 10 years. 20 wake event is not close enough to fit the application of this device. If your aim is in the sub 100 wake events this is not going to work for your application. 

    There is too much cell to cell variation for the gauge to account for with this few number of pulses. The gauge function off the change in impedance over time. Impedance is only calculated when the GE pin goes low, not while it is [GA]. So the 1.5hour discharge you are using is not being used to determine SOH.

    Thanks,
    Eric Vos

  • 0 in reply to Vos
    Prodigy 50 points

    What can you tell about the other parameters mentioned? like, terminate Voltage, EOS detection %, etc? Are correctly set? 

    Normally what I do is using the long discharge as the learning pulse and I measure it while the device is gauging (within the Start() and Stop() commands, while GA is active) and then wait 15 to 20 s to get the resulting values, and then put the battery to sleep.

    Is there any other consideration to mention? 

  • 0 in reply to Fr4n
    TI__Genius 10370 points

    Fran,

    I recommend reverting these values back to default. Pulse counter is the threshold to start looking for EOS. this should be set after about 40% of the capacity has been used. Terminate voltage please revert back to default. It is not used for EOS mode since the OCV profile for this cell is extremely flat. 

    You want to only gauge a pulse like the real application will see. The battery needs to start with OCV then follow the Gauge start, short high amplitude pulse, gauge stop, wait until G-Done routine. 

    Thanks,

    Eric Vos

  • +1 in reply to Vos
    Prodigy 50 points

    Do you think I should also revert back the Smoothing Threshold Voltage? 

  • +1 in reply to Fr4n
    TI__Genius 10370 points

    Yes i would revert all values back to default outside of the chemID. First step is to make sure you can get good measuredZ values produced. 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 50 points

    Well, I would like to answer something I just read here and I think it is important: Our application provides pulses for transmitting for around 2 minutes. Is that window too long to take measurements? Can I send a Stop_gauge command while the pulse still high and still having a descent result?

  • 0 in reply to Fr4n
    TI__Genius 10370 points

    Fran,

    2 mins should be ok. You 100% want to make sure you are enabling the [GA] prior to the load being applied, and G_Stop after the pulse has been removed. This is very critical. 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 50 points

    Great. I will do the following test to see how to get accurate measurements.  I am using the evaluation board so the setup will be faster:

    1) Turn on the system by connecting the battery (GE =1).
    2) With the load disconnected, send the Start_gauge command.
    3) Wait until GA is up. Then connect the load for 2 minutes. The load provides a discharge of 41mA and drops the voltage from 7.1 to 6.3V.
    4) After 2 min or close, disconnect the load, wait 2 seconds and send the Stop_gauge command.
    5) Wait until G_DONE is set and check the results.

    I will try this for 5 cycles, then discharge the battery for a while, and repeat it another 5 cycles. 

    I will report my results on the other post that still open and is dealing with a similar issue (which also you are helping a lot). For the moment, thanks for the provided information. 

    The post where I will continue updating is this: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1003738/bq35100-eos-impedance-measurements-with-wrong-results/3710622?tisearch=e2e-sitesearch&keymatch=%2520user%253A484197#_cptype=panel&_cpcontexttype=Explicit&_cppanelid=c2360510-559b-4c97-9cc9-760e5b71a003&replyid=3710622

    Thanks for your help