• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 63 subscribers
  • Views 464 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: End-Of-Service (EOS) Mode: unable to get an accurate and consistent reading

Yu Fei Leung
Prodigy 120 points
Part Number: BQ35100
Other Parts Discussed in Thread: EV2400, BQSTUDIO,

We're using an EV2400 evaluation kit.  We use a battery pack of 2 Li-SOCl2 batteries in parallel, 3.6V. Our application normally draws 30μA, up to about 90μA when idle, with higher spikes of up to 10mA during activity.

We're having trouble getting this working.  We followed the instructions given in the datasheet (in section [8.2.2.2.1.2]), but can't seem to get an accurate and consistent reading.

In particular we're wondering about how strict the timing is for step#3, which says to "Send GAUGE_START() 1 s prior to the high load pulse starting."  What if we start the high load pulse sooner than 1 second, or later than 1 second? How much margin do we have?

Then in step#4 it says to "Send GAUGE_STOP() directly after the high load pulse has stopped".   We have a couple questions about this step:

  • What are the parameters we should use for the high load pulse (how much current, for how long)? We think that based on the datasheet's section [8.2.2.6] that we could do something like 20 mA for 20 milliseconds. Can someone confirm?
  • We also wonder how much margin of time do we have? After we stop the high load pulse, how much time do we have before we must send GAUGE_STOP() ?

Finally, it is mentioned in step#6 that we could get other data such as State-Of-Health()? I thought State-Of-Health was a different mode, one that's mutually-exclusive from EOS? We would love to be able to get SOH data, particularly since we're using Li-SOCl2 chemistry (which we thought could not be used with SOH mode), so we'd like confirmation on this.

Thanks!

  • 0
    TI__Guru** 105590 points

    Hello,

    The gauge start command needs to be sent a minimum of 1 second before your load starts, you can do it longer before the load like 2 or 3 seconds, but don't go shorter.

    The datasheet is confusing in this section, you need a load that causes a 100mV drop for at least 100mSec to get an accurate reading.

    You can read SOH data in EOS mode with the correct chemistry ID programmed to the gauge. Check the note in section 5.3.3 in the TRM.

    Could you log the performance of the gauge and show how it is not working for your application?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 120 points

    Wyatt Keller said:

    The gauge start command needs to be sent a minimum of 1 second before your load starts, you can do it longer before the load like 2 or 3 seconds, but don't go shorter.

    The datasheet is confusing in this section, you need a load that causes a 100mV drop for at least 100mSec to get an accurate reading.

    Thanks, this really clarifies things.  We weren't sure we would be able to create a >=20mA load, but if we only need to cause a 100mV drop in the battery we're using, we believe we can achieve that with approximately 3mA load.

    Wyatt Keller said:

    You can read SOH data in EOS mode with the correct chemistry ID programmed to the gauge. Check the note in section 5.3.3 in the TRM.

    Thanks for the reference to 5.3.3 in the TRM.  That helps.  However, we're uncertain how to select the correct chemistry ID.  We updated the chemistry list to version 798 (which we believe is the latest version).  The battery we're using is an ER14250, with two of them in parallel (so we're still at 3.6V, but with a total of 2400mAh).  There's two candidates which we believe are close:

    1. Chemistry ID 0648 – Saft LS14250 (1200mAh)
    2. Chemistry ID 0647 – Ethenacell ER14250 (1200mAh)

    We tested updating and selecting each of these (using TI software, bqStudio), in order to see what data flash registers are configured (and with what values).

    We observed that Ra Table register was updated with new values (Ra0  to Ra14).  But we wonder what is the complete set of registers that would be affected by chemistry update for EOS mode?  How can we figure out the configuration values for our batteries?  Does the fact that we have a battery pack configuration with 2 in parallel affect the chemistry ID or chemistry values that we ought to use?

    Wyatt Keller said:

    Could you log the performance of the gauge and show how it is not working for your application?

    Sincerely,

    Wyatt Keller

    We'll try again for EOS gauging using the info you've given us (100mV drop for 100ms), and let you know if we still have problems.
    Thanks!
    Regards,
    Yu Fei
  • 0 in reply to Yu Fei Leung
    TI__Guru** 105590 points

    Hello,

    I'm glad this clears things up for you!

    We usually recommend using a gauge with a battery that has an exact ChemID match for this kind of battery since it is a primary battery. Having two in parallel should not cause problems, the gauge performs a calibration during the first pulses to learn the relative resistance of the batteries compared to the ChemID.

    If you run into any issues let us know.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 120 points

    Wyatt Keller said:

    Hello,

    I'm glad this clears things up for you!

    We usually recommend using a gauge with a battery that has an exact ChemID match for this kind of battery since it is a primary battery. Having two in parallel should not cause problems, the gauge performs a calibration during the first pulses to learn the relative resistance of the batteries compared to the ChemID.

    If you run into any issues let us know.

    Sincerely,

    Wyatt Keller

    Hi Wyatt,

    OK, let me re-phrase the question because I think maybe it was misunderstood.

    What we see is that parameters within the Ra table (in the DataFlash) are programmed when ChemID is set.  That's from bqStudio, but in our boards, we plan to use I2C communication from our main SOC to "manually" control and program the BQ35100, and we would not be using bqStudio.

    So our actual question is: besides the Ra table, are there any other parameters that get programmed into the DataFlash when selecting a ChemID?

    That way, when we program "manually" on our boards, we would program the correct set of parameters into the DataFlash.

    Regards,
    Yu Fei

  • 0 in reply to Yu Fei Leung
    TI__Guru** 105590 points

    Hello,

    I understand your question now, there are values that are set as private in the data flash that you cannot see with bqStudio. I would recommend you use the golden image tool once you have configured the gauge and use that df.fs or bq.fs file to program the gauges instead of manually inputting the values.

    Sincerely,

    Wyatt Keller