• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 7 answers
  • Subscribers 63 subscribers
  • Views 274 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: Battery management result do not behave as expected.

Manfred Otto
Prodigy 80 points
Part Number: BQ35100
Other Parts Discussed in Thread: BQSTUDIO

Hi TI,

i have some questions regarding the correct implementation of the BQ35100 together with a battery type ER18505M LiSOCL2 3.6V.

I do not have an eval-board nor the bqstudio to begin with.

I wrote a small driver for the bq35100 to communicate with my mcu.

My application just switches on the device every hour doing some 2-3 minute task and shutdown.

I have currently used the EOS mode and i am reading the current, voltage, measruedZ, scaledR, temperature and SOH.

I left all settings in default just changed some minor things.

I do following:

switch on the modul via GE pin waiting

reading control register checking for INITCOMP to become 1 and for EOS_BAD_OCV, SOH_ERR and SOH_MERIT=0

setting in EOS mode via writing to appropriate flash registers.

starting the modul via GAUGE_Start cmd checking via control register

write away i start my application

after coming back i switch off bq35100 via GAUGE_Stop cmd takes a time until G_DONE and GA

after that i start reading the values and shutdown

But the SOH is at beginning rapidly went down than stabilize at a number. After doing a test over weekend the values became 0.

But for sure the battery is not empty at all i still use it until now.

Also if i track the resistor value i recognize they are not differing, so the stay the same over that period?

Thanks you in advance

  • 0
    TI__Genius 10370 points

    Manfred,

    I am slightly lost by your procedure. The bq35100 device spends most of it's time off. Every time you are about to apply a pulse to the battery that you want to "Gauge" you should follow the below procedure

    1) GE high

    2) Gauge Start command

    3) Apply Pulse load

    4) Gauge stop command

    5) Wait for GDone

    6) Read parameters you care about (To start with this should be measuredZ and ScaledR)

    7) GE Low

    All 6 of these should be automated because the gauge start should be right before the load is applied, and gauge stop should be right after the load is removed.

    The goal of your first test should be to make sure you get consistent measuredZ and scaledR values. This is the impedance the gauge is calculating your impedance of the battery to be. Once you get these stable values you can compare them against the Ra table (chemID) and see where they fall for your SOH reporting.

    Please set Cell Term Voltage = 900mV. Some old legacy ChemId's had an issue where this caused SOH to decrease constantly, but i think all the ID have been fixed. This is just an added precaution.  

    Thanks,

    Eric Vos

     

  • 0 in reply to Vos
    Prodigy 80 points

    Hello Eric,

    what do you mean by applying pulse load.

    Is it not enough to just switch on the application it does some loads anyway. Or does that mean i must create some predefined loads with predictable current flows to do some testing, teaching or what else? Does the Ra(0-14) table corresponds to 100% full to 100% empty state of battery? That means i have to plot a measuredZ curve taken from my tests and comparing them with those stored in flash? So i have to sacrifice one battery to get some data and do what with them?

    My measeuredZ and scaledR are always the same in range of 780 to 1090 ohms, wildly changing back and forth. My firmware does the same as you suggest, accept that, instead of applying loads i start my application.

    Do i have to calibrate the bq35100 before using it together with my mcu?

    Thanks,

    Manfred

  • 0 in reply to Manfred Otto
    TI__Genius 10370 points

    Manfred,

    1) The bq35100 needs the load to start and stop within the gauge start/stop window. So when you say start the application i am not sure what that means. You dont need pre-defined load amplitudes, but within the window the gauge does need to see at least a 100mV voltage drop when the load is active. 

    2) Yes Ra table corresponds to full through empty, but they are not evenly distributed. there is increased resolution when you get to the end. 

    3) Yes the bq35100 should be calibrated prior to testing starting

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 80 points

    Hello Eric,

    is it a must to calibrate, because of better accuracy.

    You mentioned before that i should look after that the measreudZ and scaledR values become consistent. What do you mean by that? I see that those two values are the same at each measure. I also can not see a mayor trend they are moving uppwards downwards. I read somewhere that measuredZ = scaledR * factor, so my factor is 1. What does that mean? Seems wrong to me. And also my SOH is decreasing by the default index stored inside the flash, which is 2. Has it something to do with the lack of calibration procedure.

    I meant application is the normal task that my mcu should do. Taking some measurement reading some values sending them away and so one. There are some LDOs which i switch on and off. I not sure wheater i have a 100mV voltage drop in between the window. Does that care a lot.

    Greetings

    Manfred

  • 0 in reply to Manfred Otto
    TI__Genius 10370 points

    Manfred,

    Calibration is needed to get accurate voltage/current measurements thus accurate measuredZ calculations. 

    The fact you are seeing stable measuredZ values is a good sign your procedure is correct. ScaledR is MeasuredZ*Scale Factor. The scale factor is learned on the "Learning Pulse". If you are still at 1 you probably had an error on that pulse and will need to issue the "New Battery" command to start again learning it. 

    After you get scaledR to learn you should compare it against the Ra table to see where your value falls. 

    Lastly, Yes 100mV IR drop is needed. Without this drop the gauge will not have enough resolution to run the algorithm correctly. 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 80 points

    Hello Eric,

    so my next steps are.

    Getting an setup ready to pose 100mV drops and teach the device to get some scaledR different than measuredZ, so factor becomes not equal 1. So that tells me it has calculate something? Is it a single puls or does it take several load puls?

    For my understanding, those 100mV drops are just at the beginning and only for teaching purpose. To get maybe a lookup table to store it in device? Calibration was nothing to do with that, that comes prior. As i mentioned earlier i do not have an evm, so i have to write code for calibration procedure also? It is described in SLUUBH1C? Does it make things easier having an EVM and bqStudio?

    Thanks

    Manfred

  • 0 in reply to Manfred Otto
    TI__Genius 10370 points

    Manfred,

    The 100mV IR drop under load is needed all the time. Due to the ADC resolution and the internal math the gauge needs to detect a solid voltage drop to accurately computer MeasuredZ. 

    Yes i would say it makes things easier to have an EVM becuase the math for the calibration is built into the plug-in. At the end of the day you do need to perform calibration on your board because calibration will be different. I suggest tapping on to the I2C pins blue wire if needed and use bqStudio to calibrate with your actual board. 

    Scaling factor is learned on the "learning pulse" by default this is the 2nd time the GE pin gets set high. It is critical this pulse is successful

    Thanks,

    Eric Vos 

  • 0 in reply to Vos
    Prodigy 80 points

    Hello Eric,

    Lately Merry Christmas and new years greetings from me to you.

    Now i am little bit lost. Calibration is a one time calibration of the system and after that flashing it to all devices in series?

    So this could be done outside the host firmware.

    Can you brief me in how can i get this system running more detailed.

    What are my steps and items i have to use.

    Thanks

    Manfred

  • 0 in reply to Manfred Otto
    TI__Genius 10370 points

    Manfred,

    After soldering each device to a PCM you have to do certain actions. examples:

    1)Calibrate

    2) Setup DF

    3) Program in Chem ID

    Once these things are done you can extract a "golden image" and use this image to program the image into the other devices. For things like DF an ChemID nothing further is needed. For calibration this is where is gets a little grey. It is recommend by TI each device get calibrated individually. This would be program in golden then perform calibration on every device. 

    However, in some instances i have seen customers calibrate a handful of boards  and include the average in the golden file to skip the calibration step. This method will introduce error so it is customer dependent on if this error introduced is acceptable. 

    Calibration is normally done on the PCM manufacturing stage. 

    Hope this clears it up

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 80 points

    Hi Eric,

    so i have to do calibration this is mandatory. OK.

    Sorry what do you mean with DF, data flash? Calibration related?

    When doing so, like in production, i can use TI bqStudios and EVM to easy get my calibration and golden images done and flash each device.

    So i need to have an extra possibility to communicate with bq35100 without using the host mcu in production. This might be a layout change.

    But there is also a possible approach to put those steps and calculations in host firmware? This could rather be difficult?

    Thanks

    Manfred 

  • 0 in reply to Manfred Otto
    Prodigy 80 points

    Hi Eric,

    i have discussed those topic internally and i have some more questions.

    Can you tell me more about the shape of the load drop. More than 100mV for sure but for who long. Who long is an appropriate Gauge start/stop time level to get good measurements result and not to reach in an error. Can you give me an rough example who the measuredZ and scaledR values should continue maybe an example list. So i can have an idea.

    We like to change batteries in the field. So i guess those battery have to be calibrated as well? So calibration was to be in firmware.

    Thanks

    Manfred

  • 0 in reply to Manfred Otto
    TI__Mastermind 24870 points

    Hello Manfred,

    We are looking for ideally 100 mV for at least 2 seconds or more.

    The bq35100 is looking for an inflection point where the resistance starts increasing much more rapidly. This means the battery is nearing end of life.

  • 0 in reply to Kang Kang
    Prodigy 80 points

    Hi Kang Kang,

    those 2 seconds you mentioned, i think this is the overall measuring time? And in between there has to be an voltage drop of more than 100mV for that period of time? Because, in my system i don not have such a long drop. Just a very narrow sharp notch for 1ms after that it will rise again to battery voltage, but the drop will be 1V. Is it a problem? How can i solve that?

    Do i need to set lifetime data collection for EOS mode. Try to set it and read it back with controlregister -> 0x2080 did nothing. Also in dataflash i read the 0x426b and got negative values? Supposed not to be.

    Thanks

    Manfred

  • 0 in reply to Manfred Otto
    TI__Genius 10370 points

    Manfred,

    The bq35100 would expect the increased load to be applied for at least 32mSec. In EOS mode when the gauge is active it alternates taking V and I measurements every 8mSec. So the longer the better but a minimum of 4 samples. Ideally around 100mSec+ would be best. The gauge needs to register both Current and Voltage with the increased load in order to accurately capture the impedance. 

    You should not be configuring Flash every time. Flash updating is done only once at the beginning. 

    You need to look at the MeasuredZ and Scaled R values and compare them to the Ra table inside the flash. This correlation will determine you SOH. 

    You really should at a minimum update the chemID to a cell that looks similar otherwise you could be way off.

    Thanks,

    Eric Vos