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.

bq27532 + bq24250 EVM -- Learning Cycle/Incorrect SoC Question

Other Parts Discussed in Thread: BQ24250

Good morning, Joel.
Thank you for comprehensive answer.

1. I now perform learning of the evaluation board with follow settings:
- Design Capacity = 1180 mAh (other corresponding settings are accordingly)
- Taper Current = 100 mA
- Tapper Voltage = 100 mV
- Quit current = 30 mA
- Dsg Current Threshold = 35 mA
- Chg Current Threshold = 40 mA
It looks rather consistency for me. And for you?

2. I didn't understand about constant charging current.
What I should and what I shouldn't to do to have such complete control of my gauge?
In the current (pilot) version of our device, I control Fuel Gauge from MCU, i.e. in the init stage - "once in life" - I set all necessary data to the Data Flash. These data is obtained from learning of the evaluation board and "hardcoded" to my C-program.
In the same stage I may set proper data to the Charger registers mapped to the Fuel Gauge.
Thus the question is just which values should be set. Isn't it?

Once more, thank you very much.
Best regards.
Alexander.

  • Hey Alex,

    1) The voltage and currents look fine to me. I want to be clear that a normal charge profile for Li-ion looks like Figures 15 and 16 of the bq24250 datasheet, but I think you know that already. As soon as the CV loop is hit, the charge current will taper down until charge terminates.

    2) So after reading the bq27532's technical reference manual, one thing to make sure that Charger Control Options >> STEP_EN is NOT set. This will enable MLC charging scheme, which is multi-level charging that changes charge current throughout the cycle. Charger Control Options >> DEFAULT_OVRD should also be set to 0.

    In Control() command >> subcommand MLC_DISABLE should be instantiated. This bases the charge profile to be based on the charge temperatures tables.

    You will then need to update the Data Flash - Charger Class data, under Temperature Table subclass, and change the "Charge Current Tx" values to the %C (where C is the Design Capacity you program) to equal the constant current you want. This table defines the battery temperatures and %C currents you want in those temperature ranges, so please follow you battery manufacturer spec for this (at least for hot and cold temperatures).

    This should give you a standard charge profile at the current you are looking for.



    Hope this helps.


    Regards,
    Joel H
  • Good day, Joel.

    I'm very appreciate your participation in resolving my problem.
    Last week I have performed IT learning on the EVB with our battery and filled our custom boards's Fuel Gauge's FMEM with those just obtained data.
    And it seems like Fuel Gauge works wrong - it shows Remaining Capacity and based on it State of Charge inconsistent with Voltage and practical observation - i.e. almost full charge after charging during several minutes after almost total discharge.
    I sincerely suspect that
    - either my learning process was not so successful,
    - or I transferred learned date with inconsistency,
    - or I run all of staff in improper way.

    Do you know whom I may address to?
    My goal is quite simple - be able to obtain State of Charge of the battery with known Qmax (Design capacity) and Chem ID.
    The single - I cannot force a final user of the device to perform some stages to provide IT learning of the Fuel Gauge.
    Thus I'm going to perform it in my code via MCU.

    I hope that brief concentrating on specific details and several rules should resolve my problem.
    The question is whom I may address to.

    Thank you in advance.
    Best regards.
    Alexander.
  • Good day, Joel.

    Once more piece of my observation.

    When I disconnect my pretty discharged (SoC 72%) battery from the board and reconnect it , the Fuel Gauge "counts" it almost full charged (SoC 99%).
    Is such behavior is predefined? Whether such symptoms were observed in your labs?
    Probably it's the root of my problems which were described in my previous post.
    As far as I understand, the optional solution or workaround is to let just-connected battery (i.e. unknown SoC) to be charged several hours to be really full charged and just after it to decide about its SoC. Am I right?

    Thank you in advance.
    Best regards.
    Alexander.

  • Hey Alex,

    So from your first previous post, it may be due to an improper learning cycle performed on the battery. The observation from your second previous post may also be attributed to the same, but I am not sure if it is defined.

    My experience is focused on our chargers and not fuel gauging. So to get you a more insightful answer, I will split this post and post a new thread on your behalf on our Battery Management - Gauges forum.
  • Good day, Joel.

    1. Regarding splitting my post, thank you.
    2. Regarding charging with unknown real SoC, may I assume the battery is full charged, if charging current is 0?

    Best regards.
    Alexander.