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.

BQ27426: Based on the application scenario, FuelgaugeIC can correctly match the battery verification program

Part Number: BQ27426

Hello,

Background:

Because of our application scenario, the battery is in Relax state for a long time, and the battery will be recharged only after the battery self-depletion (current <1mA) reaches a certain value.

FuelGaugeIC's Sleep mode has a current of 10mA. i.e. the process of battery self-depletion is not sensed by FuelgaugeIC.

Recharge interval:RM<278mAh to recharge; RM>318mAh to stop recharging and keep Relax.

Problem Description:

In order to verify that the Filtered FCC of the FuelGaugeIC can be correctly matched to a new battery during the aging process, we envisioned the following scenario.

Charging is done through the FuelGaugeIC with a charge current of 390mA;

Discharge the battery without the FuelGaugeIC, using other circuits to discharge the battery.

Question:

1, Is this solution feasible and can Filtered FCC track the aging process of the battery?
2, When discharging a battery through other circuits, where the current does not pass through the FuelgaugeIC, and the FuelGaugeIC has access to the battery voltage, does the RM value change during or at the end of the discharge process? Will it match the battery voltage?

3、If it is not feasible, please advise why?

4、If it is feasible, is it necessary to add Relax time between charging stop and discharging stop? What is the specific time setting?

Best Regards.

  • The gauge doesn't rely on coulomb count. It uses a complex algorithm that also takes OCV measurements into account. It doesn't matter, if the current is tiny - the gauge will consider cell voltage == OCV and update DOD periodically, which will cause true RM to drop accordingly. You can issue the SMOOTH_SYNC command if you have smoothing enabled to update filtered SOC, RM and FCC.

    The gauge usually won't update filtered SOC, RM and FCC while in relax (unless explicitly configured to do so if temperature changes significantly). In a use case like this, I recommend issuing the SMOOTH_SYNC command if you want to know filtered SOC, RM and FCC during long relax.

  • Hello Dominik,

    We performed 5 cycles charge<->discharge verifications following the test method described above, using three batteries with SOHs of 89%, 77% and 64%, respectively.

    Sending SMOOTH_SYNC commands at 30 minute intervals

    Filtered FCC and True Fcc are currently 695mAh for all three devices.

    1, What is the reason for the same FCC value?

    2, Is the test cycle sufficient? How much Cycle is needed?

    Attached is the Test log, the log contains all DOD, PassedCharge, DOD final, DODatEOC, etc.

    FCC Test Log.zip

  • #1: It's unlikely that all three devices show the exact same FCC, if the gauge learned Qmax, Ra, charge termination and load for each device. So this is either a coincidence or the gauge didn't learn these parameters.

    #2: You need at least one strict dedicated learning cycle (with UpdateStatus = 0x03 at the start) which allows a Qmax update first (during charge), followed by an Ra update. Or you need several (number depends on how different Qmax and Ra are compared to the GoldenImage) regular cycles.

  • Hello Dominik,

    #1, Problem background:

    All three devices are loaded with Fs files made from new batteries.

    We communicate with TI Shanghai FAE about the results:

    Batteries with SOH>80%, do not need full charge and full discharge, there is a charge and discharge process, FuelgaugeIC can match the FCC of the battery.

    Batteries with SOH<80% need to be fully charged and discharged for the FuelgaugeIC to match the FCC of the battery.

    Our objective:

    In conjunction with our application, verify that batteries with SOH>80%, load the Fs file of a new battery, and that the FuelgaugeIC can match the FCC of the battery during use.

    Test steps:

    step1: Charge to RM>316mAh,charge current 390mA.

    step2: Relax 5 hours

    step3:Discharge to Vbat<3880mV.

    step4:Relax 5 hours

    step5:End of round 1, continue with step1--step4

    note:Sending SMOOTH_SYNC commands at 30 minute intervals

    Question:

    Q1: How can we validate the purpose of our test?

    Q2: How to make FuelgaugeIC's FCC match correctly for batteries with different SOH without performing a full learning cycle?

    Q3: Based on your previous reply, our understanding is:
    For our application scenario, FuelgaugeIC's Fcc can gradually match the batteries during the battery usage. Is this understanding correct?

    The gauge doesn't rely on coulomb count. It uses a complex algorithm that also takes OCV measurements into account. It doesn't matter, if the current is tiny - the gauge will consider cell voltage == OCV and update DOD periodically, which will cause true RM to drop accordingly. You can issue the SMOOTH_SYNC command if you have smoothing enabled to update filtered SOC, RM and FCC.

    Q4: What time period do you answer cases on e2e from US time to time? I would like to make an appointment with you to communicate with you online in real time.

  • The test looks ok. The relax times can likely be reduced to about 1.5 hours.

    A1: I'm not sure how to answer this question. There's a chicken and egg problem. If you use the gauge SOH feature, you won't know SOH until the gauge learns but you need to know SOH to judge what learning method to use.

    A2: You can't. The gauge will not allow large changes of cell parameters in a regular cycle (non dedicated learning cycle).

    A3: Yes, the gauge will eventually converge. This is a core aspect of the algorithm.

    A4: The team (including me) is on-line during regular work hours, central time USA.

  • Hello Dominik,

    The SOH in Case is not the register value in FuelGauge, but the value we measured with the measuring instrument. Measurement method: Battery 0.2C charge to 4.4V->Relax 30min->0.2C discharge to 3.3V, record the true SOH of the battery based on the discharged capacity/designed capacity of 1230mAh.

    Question:

    Q1:When the battery is known to have SOH>80% and plugged into the device, there is  charging process and discharging process (discharging does not pass through the FuelGaugeIC), is it possible for the FuelgaugeIC to match the state of the battery step-by-step?

    Q2:If Q1 is Yes, what is the approximate number of charging processes needed for the FuelgaugeIC to match the state of the battery?

    note:Charging to RM ≥ 316mAh, Relax until the battery self-depletes to RM < 277mAh, charging again to RM ≥ 316mAh. keep cycling.

    Q3:If Q1 is No, how can the FuelGaugeIC match the state of the battery when not performing a full fill and discharge?

    A1: I'm not sure how to answer this question. There's a chicken and egg problem. If you use the gauge SOH feature, you won't know SOH until the gauge learns but you need to know SOH to judge what learning method to use.

    Q4:The FS file was created based on a new battery with a design capacity of 1230 mAh. inserting a battery with a capacity of 1230 mAh ±??mAh will satisfy the modified conditions for regular use。

    A2: You can't. The gauge will not allow large changes of cell parameters in a regular cycle (non dedicated learning cycle).

    Attached is the Fs file.

    3817.0418_New_Bat_FS_withChemID_0419.gm.zip

  • A1: Both charging and discharging currents must pass through the gauge for this to work.

    A2: The gauge requires charge and discharge cycles. There is no way around this. The depth during regular use is a minimum of approx. 35% Qmax. The gauge will also not adjust Qmax and Ra without filters. It is not possible to give you concrete numbers how long that takes as this depends on your cell, the load, the charge termination conditions, temperature, age.

    A4: When looking at capacity, key is Qmax for the cell that was used for the Golden Image. The error of the gauging results will track with the difference in Qmax (though it's not a simple formula). So the higher the difference of Qmax for the cell vs. the one from the Golden Image, the higher the error. In general +/-3% is ok. If its more then you will need to wait until the gauge updated Qmax several times until the gauge is accurate.