• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 1173 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.

BQ35100: EOS impedance measurements with wrong results

Fr4n
Prodigy 50 points
Part Number: BQ35100

Hi TI support team

I have posted before how I am trying to determine the uncertainty of this device (https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1002242/bq35100evm-795-eos-improving-accuracy-and-measuring-uncertainty/3704875?tisearch=e2e-sitesearch&keymatch=%2520user%253A484197#3704875).

Currently, I am performing a new test with a fresh pair of batteries (Saft LF 14500, 2.6Ah, 3.6V), but it has been really complicated:

I got terrible results on my first measurements: the EOS flag never raised, the calculated values reported errors, and most of the measurements were complete nonsense since the relaxation time I was giving was just 2 hours. SOH_MERIT, EOS_BAT_OCV, and EOS_ERR flags were always present. Right now I am repeating the test but I still having weird results:

1) Short or Long term averages are not being calculated. It always marks as 0 and the EOS detection count Thrsld counter didn´t increase on the current measurements.
2) The impedance values are too high and also the scaled and measured impedances are the same (around 10000).
3) SOH stood steady at 98%
4) I am not having EOS_ERR or EOS_BAD_OCV, but SOH_MERIT is present.
5) I have the following configuration:

  • I am connecting directly the batteries (2 cells in series) to the evaluation board BQ35100EMV-795 (Saft LF 14500, 2.6Ah, 3.6V)
  • The discharge process is as follows
  1. Connect the batteries to the evaluation board. BQ35100 was previously calibrated at 1A and 8V
  2. I loaded the corresponding chemistry.
  3. I sent the command NEW_BATTERY (It gave an error, but the stored values corresponding to the battery were restored).
    1. I set in Operation Config A: EXTVCELL=1, LT_EN=1, GMSEL= 10 (EOS mode)
    2. EOS data: New bat R scale delay = 2 (default)
    3. EOS trend detection % = 15
    4. EOS trend detection threshold = 16
    5. EOS EOS trend detection pulse counts = 0 when I inserted the new battery. It was changing before after a Start/Stop cycle, but it didn´t change after.
    6. EOS smooth start voltage = 4800V (Below this value, the device just stop working)
    7. SOH delta = 1%
    8. Terminate voltage = 3800mV
  4.  When I want to start the pulse, I press start() (when the GE is enabled)
  5. after 5s, I connect the load, which is just 160 ohms resistor to provide a discharge of 40mA, which causes the battery to drop its voltage from 7.1 to 6.8V (so the drop delta is 200mV)
  6. I left it for 1hour 30 min. After that, I disconnect the load and press Stop().
  7. Wait for 15s, get the results and I disconnect the battery.

After doing this 4 times (4 measurements), I got too high impedance values (around 1000 mOhm, and I am expecting just 3000 or 4000), and the SOH barely changed 1% per discharge. I am giving 5 hours of rest between pulses and more than 10 hours when I go to sleep. It seems the SOH_MERIT problem is not caused by a stressed battery because even in the other case, I still having odd results. Nothing else is connected between the battery and the gauge, and the EMV is configured correctly according to the respective documentation (jumpers are placed in the right place). 

Right now I don´t know what else to do. I have looked at the forum but most of the time, things get solved because the user is using the wrong chemistry, using old/used batteries, or setting up wrong values for the configuration. I did everything as is instructed on every documentation (Datasheet, TRM, EMV manual, and slua904) and still, I am not having the right results...

Can you tell me why I am having these wrong results? I am doing something wrong? I will still conduct the test just to see if I get something fair after more measurements, but at this moment, everything looks pretty bat. Please help :( 

  • 0
    TI__Genius 10370 points

    Fr4n,

    You say you leave the load connected for 1.5Hours. That is not the intended use for this device. This device is intended to gauge pulses on the magnitude of 2 seconds. You are most likely overflowing the filter with measurements. Is this your true application? 

    Which ChemID are you using?

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 50 points

    The application is for a GPS system. There is a supercap providing energy to the system and the batteries should charge it for around 10 seconds at 85mA after transmitting. Also, the idea is to conduct the test in the shortest time possible so it would not take me 1 month to see any result. 

    The chemistry ID is the one corresponding to that battery (SAFT LS 14500), which chemistry is the one recommended for this application (Li-SOCl2)

    Can be possible to conduct the test in such a way that it would take me at least 1 week and not 1 month? like measuring the system by giving a pulse for measurement, and after, giving a long discharge (without measuring anything during this discharge), followed by 5 hours of resting? 

    Thank you for your answer.

  • 0 in reply to Fr4n
    TI__Genius 10370 points

    Fran,

    You would need to follow a test flow like the following

    1) Pulse Dsg

    2) Rest like your application would

    3) Loop 5-10 times

    4) Dsg extended time (gauge off)

    5) Rest extended time to recover from long Dsg

    6) Loop back to #1

    Primary cells are not easy to work with and testing/validating takes a long time. If you rush the testing it will invalidate the data because of the passivation layer effect these batteries go through. 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 50 points

    HI Vos,

    The profile from my application is similar to give a 50mA pulse for almost 2 minutes. I will use that pulse on the real application to take the measurement. 

    I will follow your advice posted in another post, and I will perform for this weekend the following test:

    I Will the following loop for 5 cycles without long deep discharges:

    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.
    6) Disconnect the battery
    7) Wait for 4 to 5 hours to give a rest to the battery

    I will repeat this (as I said) 5 times. After the last, I will provide a discharge for 2 hours (to get different reads) and then a longer rest (around 8 hours). Then I will repeat the measurement loop. My goal is to have at least 3 measurements per day until the battery is drained.
    -----------------------------------------

    On the other hand, I am really concerned about my current results: The averages are quite different already (more than 20%), and my calculations point out that the battery's current capacity is around 70% (although the SOH says it is 80%). Basically, every time I give a cycle, it drops 1% although nothing was changed on the system. In addition, The SOH_MERIT error has popped up many times (there were only two situations where it didn´t rise, and it was when I sent 5 short pulses of around 2 seconds during a Sart/stop cycle). 

    Why SOH_MERIT still there although the battery is well rested? 


  • 0 in reply to Fr4n
    Prodigy 50 points

    Hi Vos, I have some update:

    I got the "EOS" flag because I gave as EOS trend detection threshold = 30 cycles. After the 31st cycle, the averages (Long Term and Short Term Average) were sufficiently different enough to give the EOS flag. 

    The SOH_MERIT was present all the time. I have read the following post: 

    https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/963480/bq35100-locating-the-cause-of-soh_merit/3563310#3563310

    And also the referred post: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/833628/bq35100evm-795-eos-for-lisocl-eve_er34615-19000mah-batteries-soh-keep-dropping-by-soh-max-delta

    Both posts state the SOH_MERIT problem would not prevent me from measuring the impedance, however, I think this is affecting the average calculations. I tried the "hack" suggested on the second post to reduce the voltage before sending the START() command and sometimes worked and some others didn´t. Even giving a long rest, this error didn´t disappear.