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.

BQ78350-R1: something happens with FCC parameter

Part Number: BQ78350-R1
Other Parts Discussed in Thread: BQSTUDIO

Dear support,

we have an issue with fuel gauge especially with the FCC parameter.

We did learning cycle. Charge -Discharge-Charge to full. The cylce where made in our devices with BQ24610RGET charger. Battery pack was checked in charge and discharge condition. Later on the Device was switched off and carried to stock. After three weeks we checked device and switched it on by battery. RSOC was decreasing very fast and steppwise. For example from 90% directly to 7%. We analysed parameters with bqstudio and figured out FCC parameter was very low. Should be arround 2700 mAh and was 174 mAh. The learn parameter was not there anymore. How can this happen?


While device is in stock battery gets discharged by device with 3 mA constant current.

best regards

Ingmar

13629.gg.csv

  • Hi Ingmar,

    When you power off and power on the device, all of the device registers are cleared, so information that is not stored in data flash is lost. When the device powers on, it can only estimate the SOC based on the cell voltages (see TRM section 9.1.4 Initial Battery Capacity at Device Reset). It determines this based on the ChemID that has been loaded into the device. The process for selecting and programming the ChemID is discussed in more detail in the Gas Gauging section of this document: https://www.ti.com/lit/an/slua924/slua924.pdf An accurate ChemID will help to better estimate SOC on power-up.

    When there is a qualified discharge to the EDV2 voltage, the SOC will drop to 7% and the FCC will be updated with the new learned value. You can limit how much the FCC can change by properly setting the FCC Learn Up and FCC Learn Down limits in data flash. Currently you have both of these set very high. Normally you should set these to a much lower percentage of the Design Capacity

    Best regards,

    Matt

  • Hi Matt,

    the ChemId were not set correctly. I have now update the ID and will now continue testing fuel gauge. Could a wrong ChemId explain our problem?

    Furthermore in section 9.1.2 Fuel Gauge Operating Modes there is an parameter called (–)Dsg Current Threshold. What does this parameter exacly mean? Currenty parameter is set to 100 mA and our device will need 3 - 4 mA in standby and ~ 250 mA in idle mode. Will fuel gauge always update remaining capacity or do we have to set (–)Dsg Current Threshold to 1 mA for example?

    best regards

    ingmar bott

  • Hi Ingmar,

    The ChemID will determine the SOC after a Reset, so it is definitely important in the situation you described. 

    It is also important to set the key gauging parameters like Dsg Current Threshold, Chg Current Threshold, and Quit Current, because these determine the states for different protections and for FCC Updates. 

    Best regards,

    Matt

  • Hi Matt,

    okay I understood. Could you please tell me what is the definition of Quit Current and will SOC updated within  Quit Current?

    best regards

    Ingmar

  • Hi Ingmar,

    SOC will still be updated below Quit Current. This parameter should be set lower than the other currents (see the illustration in the TRM) since it determines the state. FCC will not be updated below Quit current.

    Best regards,

    Matt

  • Hi Matt,

    what happens with FCC parameter when device goes into shutdown mode and comes back after a while? Is it lost or will device initialise FCC with designed capacity?

    Regards

    ingmar

  • Hi Ingmar,

    The FCC is saved in data flash so it is not lost. The parameter name is Learned Full Charge Capacity

    Best regards,

    Matt

  • Hi Matt,

    we change ChemID to the right one and also did some changes on quit parametern. Unfortnatly we still have an problem with calculated capacity. The remaining capacity is not taking into account small current flew into our device in standby. I told you our device is using 3 mA in standby and in IDLE 250 mA. IDLE is working and standby not. I did one test in standby over 2 days with a learned capacity of 2662 mAh and after 3 days a read out 2643 mAh as remaining capacity. Therefore only 19 mAh where accumulated but device definently took 144 mAh.
    In datasheet we found under 12.2.7 a parameter current deadband with 3 mA default. Could this be the reason why calculation is not proper working because our device is needing 3 mA in this case?

    best regards

    Ingmar

  • Hi Ingmar, 

    Yes, the deadband parameter is important. However, there are two deadband parameters - Current Deadband and Coulomb Counter Deadband

    The Coulomb Counter Deadband is the one that is important for accurate gauging. This value should be updated to '9' for optimal performance. Setting it to zero will cause noise to accumulate over time.

    If there is any current that does not go through the sense resistor path (is not measured by the gauge), there is also a parameter Electronics Load that can be used to account for this.

    Best regards,

    Matt

  • Hi Matt,

    I am not sure if you understood me right. I mean with our device the device where the pack will built in not the pack itself. The device will discharge battery in mimium with 3 mA and we need to counter this. When we set Coulomb Counter Deadband to 9 mA fuel gauge will not counter it. We thought we have to set it to maybe 2 mA and Current Deadband also to 2 mA. Is this right?

    best regards

    Ingmar

  • Hi Ingmar,

    The Coulomb Counter Deadband is not in mA units. It is in nV. I suggest you change the value from the default (38 nV) to 9 nV. This parameter tells the gauge not to count current below a level that results in 9 nV across the sense resistor. The Current Deadband is different - it only affects the current measurement using the Current() command which will report 0 if the current is below the deadband setting. 

    I am not sure why the default of 38 nV is preventing the gauge from tracking the 3 mA though. Have you calibrated the CC Offset and CC Gain? What size sense resistor are you using and are you using any scaling?

    Regards,

    Matt

  • Hi Matt,

    sorry for my late reply. Calibration of CC Offset and Gain didnt solve the issue. We use a 5 mOhms sense resistor.

    Since we changed Coulomb Counter Deadband we notice RSOC will be updated for a short time (2-3 days) and then it stucks.

    We are wondering if resolution for mesurement of current isnt enough? We only have 15 µV resolution and when we discharge with 3 mA we will reach this border right?

    Regards

    Ingmar

  • Hi Ingmar,

    I think that might be it. The sense resistor value is making it difficult to measure the resolution you need. 

    Regards,

    Matt

  • Hi Matt,

    is there any way for amplifie the current? Currently it is not possible to redesign BMS.
    Should we also set sleepcurrent under 3 mA for better gauging?

    regards

    Ingmar 

     

  • Hi Ingmar,

    Adjusting the sense resistor value would be best, but if this is not possible maybe lowering the Sleep current will help some because the gauging will update more frequently when the device is not in sleep. There is also the Electronics Load parameter to help adjust SOC based on a small constant load. It only goes up to a few hundred microamps though and I don't know if you load is constant or not.

    Regards,

    Matt

  • Hi Matt,

    I lowered sleep current and so far its working now. So the question is what is the difference in capacity counting when IC is in idle mode compared to sleep mode? Though it will also count and time while sleeping will also taking into account?

  • Hi Ingmar,

    When the device is in Sleep mode, measurements are taken less frequently. Current is measured every 20 seconds by default - this time period can be adjusted. Maybe this is somehow having an effect on the accuracy.

    Regards,

    Matt

  • Hi Matt, really thank you for all of your help. We believe we have now found a stable situation and will go deeper in testing.

    best regards

    Ingmar