• State TI Thinks Resolved
  • Locked Locked
  • Replies 37 replies
  • Answers 7 answers
  • Subscribers 65 subscribers
  • Views 806 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.

Original question:

bq40z50-r1 Q: how to fix FCC during discharge

BQ40Z50-R1: BQ40Z50-R1 FCC is different

Star Xu
Genius 9645 points
Part Number: BQ40Z50-R1
Other Parts Discussed in Thread: BQ40Z50, BQSTUDIO, BQ4050

Hi

The customer use the same battery cell and the same firmware, set the CHGFET=1, RSOCL=0

Test with two boards with a same battery pack, but there is 30% difference in FCC.

Attached the log data and gg file.

BQ40Z50 1.logbq40z50 2.log

BQ40Z50R1.gg.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
* Texas Instruments Data Flash File
* File created Mon Jun 07 11:18:32 2021
*
* Device Number 4500
* Firmware Version 1.06
* Build Number 36
* Order Number 0
*
* bqz Device Number 4500
* bqz Firmware Version 1.06
* bqz Build Number 36
*
* Field Order: Class name Subclass name Parameter name Parameter Value Display Units
Calibration Voltage Cell Gain 12122 -
Calibration Voltage Pack Gain 49590 -
Calibration Voltage BAT Gain 48763 -
Calibration Current CC Gain 2.079 mOhm
Calibration Current Capacity Gain 2.079 mOhm
Calibration Current Offset CC Offset 0 -
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

What is the cause of this? 

Waiting for your reply.

Thanks

Star

  • 0
    TI__Guru** 104905 points

    Hello Star,

    What is the full testing procedure? Are the batteries inserted and the first cycle used to determine the FCC difference?

    After the second cycle the FCC values should be very similar, after the field Qmax update. Depending on the start conditions it can lead to initial errors, but after the second cycle most of the gauging parameters should be the same.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello, I am the application side, as shown in the log file, I do the following loop test: charge-relax-discharge-relax-charge. I used a 3S3.8Ah battery assembly test, and the charging voltage was 10.8V. After the cycle test, 70% of the batteries have an FCC of about 3.7AH, and 30% of the batteries are only about 3AH.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    I assume this is LFP battery since the charge voltage is so low, if this is the case I would recommend making sure you set the FC bit on full charge so the gauge estimates the OCV voltage. Otherwise it may not predict correctly because of the long settle time of the LFP chemistry.

    What was the Qmax of the batteries that showed lower FCC compared to the 70% that showed higher FCC?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello, the lower FCC is only about 3000 at the beginning, it will rise to more than 3,500 after relax for a period of time, and the QMAX is more than 3,600.

    The higher FCC is about 3700, and QMAX is more than 3700

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    The FCC is a calculated value based on the Qmax and Ra table along with the temperature and load mode/select settings. You can look through the app note SLUA450 for more information on how it's calculated.

    After a relax or when the FC is set the Qmax changes? For LFP batteries the gauge will update Qmax right when the full charge is detected if LFP_RELAX is enabled. From what it sounds like after another cycle the FCC is corrected near the actual design capacity?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    1. I have seen SLUA450, but I can't find a solution. My configuration is RSOCL=0, CHGFET=1, charge cutoff depends on SOC, SOC=FCC/design capacity. If the SOC reaches 100% in advance during charging, the BMS will protect it in advance, and the battery capacity will be low.
    2. LFP_RELAX=1, OCVFR=1, according to the customer, QMAX should be updated after some time, and FCC has been corrected. But the actual FCC of the battery is still low.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    The equation for FCC is: DataRAM.Full Charge Capacity( ) = Qstart+ PassedCharge + RM

    The equation for SOC is: DataRAM.State Of Charge( ) = DataRAM.Remaining Capacity( ) × 100/ DataRAM.Full Charge Capacity( ).

    I'm not sure what I understand the BMS will protect the battery if SOC is 100% and the battery capacity will be low?

    If the OCVFR bit is set that means it can take the gauge up to 48 hours to take an OCV measurement, that is why the Qmax should be updated quickly using LFP relax. The actual FCC of the battery is low, how did the gauge correct it?

    Sincerely,

    Wyatt Keller 

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello

    1、When GaugingStatus()[TC] is set AND FET Option[CHGFET] = 1, the CHG FET turns off.

    2、If SBS Gauging Configuration[RSOCL] = 0, RelativeStateOfCharge() and RemainingCapacity() are

    not held at 99% until charge termination occurs. Fractions of % greater than 99% are rounded up to

    display 100%

    3、TCSETRSOC=1, SET % RSOC threshold=100%

    4、Because the cell voltage is less than 3500mV when the SOC is 100%, the capacity charged into the battery at this time is very low, and the normal charging cut-off voltage is 3600mV

    5、I don't know how to correct it. The customer's feedback is that the FCC is only around 3000 at the end of the charge. Without any external action, FCC will have almost 3,600 for a period of time.

    6、At present, what I want to solve is how to make the charging cut-off voltage higher so that more capacity can be charged

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    If you are trying to increase the charge time to get full capacity out of the battery and for the gauge to see that change, you will need to modify the gauge and charger. Charger taper current should be lower and the gauges VCT parameters will need to be adjusted to reflect that.

    FCC can vary based on the load select, Qmax, Ra table, and temperature as I mentioned before. It's normal to see FCC fluctuate, if RSOC jumps then that would be an issue we can look into more for smoothing.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    1. The charger voltage customer is not allowed to change. When RSOCL is set to 0, VCT is determined by the algorithm, and the voltage and current settings have no effect.
    2. The capacity of my battery is 3800mAh. With the same programming file, the same batch of BMS, and the same batch of batteries, most of them have a capacity of about 3700, and only a small part is only about 3000.
    3. When the abnormal BMS BQ40Z50 is replaced, recharge and discharge, the FCC learns normally, which can reach about 3700.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    As I mentioned before the gauge may have updated to the incorrect Qmax from the LFP_RELAX bit, FCC can vary as long as you're not seeing RSOC jumps I would not be concerned of the behavior because the gauge should correct itself over time if it calculates Qmax too low.

    Are you uploading the golden file to the gauge and then it adjusts Qmax that low? Or is this occurring when you try to do a learning cycle on a lot of gauges?

    Can you share more data of the tests being done with the .gg file pulled before and after the test while logging the test with bqStudio?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    1. There are individual SOC jumps, not many. SOC keeps about 70% and ships to customers, and it becomes 90% for a period of time.
    2. This product has been given to customers. At present, I have two sets of data, with attachments in front. The gap is not very big.
    I have a set of data of a few days after charging and discharging, you can refer to it.6505.bq40z50 2.log

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    it looks like there's a RSOC drop near EDV, enabling the FF_NEAR_EDV may help with this. It also doesn't look like the gauge is updating the DOD values at the end of charge, which should be occurring when FC is set and LFP_RELAX is enabled. Were there any modifications done to the .gg file? Can you share the .gg file from before and after the test?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,

    20211026 bq40z50.logRSOC drop should be caused by QMAX update after 24H. The attachment is the test data obtained by relaxing a fully charged battery for a period of time, and then re-burning the srec file. There is no big problem with this FCC. Currently I don’t have a battery with a big deviation

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    The log data shared looks good, no RSOC jumps, FCC is updated every time the OCV is taken over time, looks like a nominal test. You're saying they saw on one battery the RSOC went from 70% to 90% when it arrived at the customer?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    1. No RSOC jumps is because I set OCVFR=1, and I need to wait 48H to update QMAX. It hasn't been 48 hours after it is fully charged, so the SOC has not changed. There is more than one customer, there are a small number of thousands. I have a gg file attached in front of me, so I can help confirm what will affect it. The SOC is maintained at 70% when shipped, and the SOC has jumped greatly after the customer has stored it for a period of time.
    2. My FCC data is very small at the beginning, I changed a BQ40Z50 and re-tested it normally. I want the client to find a bad one and retest it.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    If the jump occurs when an OCV is taken that indicates a bad chem ID match. Sometimes if a reset command is issued while the batteries aren't relaxed it can also force the SOC to change based on the voltage.

    The only reason the SOC should change during relax and taking OCV measurements is if the chem ID does not match well, otherwise it will follow the OCV table. LFP battery chemistry can make that more difficult for the gauge and could lead to SOC errors in relax also.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    1. Today, the customer sent me the data. It was charge-discharge-charge-discharge for 38 minutes. At this time, the SOC was 67%. After a period of time, the SOC was slowly restored to 95%. Is this caused by RELAX_SMOOTH_OK =1 SMOOTH=1. During RELAX, the voltage slowly rises and the SOC also starts to rise?
    2. I re-tested the ID yesterday, and it will take a few days to learn the file. In the past, the ID deviation value was 8 o'clock, and the data of iron and lithium was relatively high.
    3. The FCC will try it with the new learning documents at that time, but I don't know why.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    It looks like from the log the gauge takes an OCV measurement and calculates the FCC and RemCap much higher, so it slowly moves SOC because of the smoothing functions to the new calculated value based on the chem ID.

    I believe this is because of the chemistry (LFP) has very flat OCV. What is the chem ID being used?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello, chem ID is 457

    I set both relax_smooth_ok and SMOOTH to 1, and then re-tested to see the results. The ID has been tested several times and the deviation is large. If the ID cannot be solved, is there any way to solve the SOC and FCC problem?

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello，new ID report

    GPC_report1.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Chemistry ID selection tool, rev=2.52
    Configuration used in present fit:
    ProcessingType=2
    NumCellSeries=1
    ElapsedTimeColumn=0
    VoltageColumn=1
    CurrentColumn=2
    TemperatureColumn=3
    Best chemical ID : 457 Best chemical ID max. deviation, % : 7.63
    Summary of all IDs with max. DOD deviation below 15%
    Chem ID max DOD error, % Max R deviation, ratio
    457 7.63 1.3
    400 7.92 1.12
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    GPC_report2.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Chemistry ID selection tool, rev=2.52
    Configuration used in present fit:
    ProcessingType=2
    NumCellSeries=1
    ElapsedTimeColumn=0
    VoltageColumn=1
    CurrentColumn=2
    TemperatureColumn=3
    Best chemical ID : 457 Best chemical ID max. deviation, % : 7.95
    Summary of all IDs with max. DOD deviation below 15%
    Chem ID max DOD error, % Max R deviation, ratio
    457 7.95 1.27
    400 8.11 0.99
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    GPC_report3.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Chemistry ID selection tool, rev=2.52
    Configuration used in present fit:
    ProcessingType=2
    NumCellSeries=1
    ElapsedTimeColumn=0
    VoltageColumn=1
    CurrentColumn=2
    TemperatureColumn=3
    Best chemical ID : 457 Best chemical ID max. deviation, % : 7.51
    Summary of all IDs with max. DOD deviation below 15%
    Chem ID max DOD error, % Max R deviation, ratio
    457 7.51 1.26
    400 7.94 1.05
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    roomtemp_rel_dis_rel 3.csv

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    Is the log you shared previously (SOC jump.log) what your application discharge looks like? Sometimes with LFP batteries the voltage is so flat the impedance track algorithm is not able to correlate. I took a look at this chemistry ID and it is very flat until almost 0% SOC.

    In the cases where you have fairly nominal discharges and temperature near room temperature, coulomb counting algorithms would perform better, like the CEDV. I would recommend looking into the BQ4050 since the chem ID is not an ideal match and it's LFP chemistry.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello
    1. (SOC jump.log) is the data before the shipment test. How should this be solved? There are currently tens of thousands of finished products that cannot be shipped.
    2. The BQ4050 has been prepared for a small batch of trial production, but the SOC and FCC problems of the BQ40Z50 are not known how to solve it.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    The SOC jump will always remain during relaxation periods, because the chemsitry itself has very flat OCV and your chem ID match is not good.

    If you have constant current discharge while mostly in room temp the BQ4050 using CEDV may track better than the Impedance Track algorithm.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    How to deal with the products currently waiting to be shipped? Is there no other way to solve it? If this batch of BQ40Z50 problems cannot be resolved, millions of dollars will be lost. Is there any configuration of data memory that can optimize FCC and SOC issues?

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    Sorry for the delay, I wanted to discuss with a coworker any other options we have. I think the best option right now would be to disable the RSOC from being able to move when in relax mode. Then whenever you start a charge or discharge the smoothing engine and Ra table will help adjust to the correct RSOC.

    Is the .gg file from the original post correct? If it is the RELAX_JUMP_OK is already 0, which means RSOC shouldn't jump in relax mode.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello，

    The RELAX_JUMP_OK is already 0

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    This should prevent large RSOC jumps during relax, can you confirm if it's disabled for the logged tests. RSOC should not move in relax mode, unless the gauge is not in relax during the rest period (no current)

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    1. The configuration file and SOC jump file of BQ40Z50 have been uploaded before. RELAX_jump_OK has indeed been set to 0, and there is indeed no current.
    2. The customer sent a copy of the latest FCC low log file. The file shows that the FCC has been updated twice, one is when the discharge ends, and the other is when the discharge is left to stand for 5 hours. The charge cut-off is not updated by the FCC, the RemCap at the charge cut-off is only 3046mAH, and the charge cut-off voltage is 3469mV.

    lowcap 20211108.log

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    It's normal to see some small SOC jumps during relax, I would recommend enabling the 48hour wait to give the best chance of the voltage relaxing to the correct DOD.

    Let me contact Star to see if there are some other options we have to help.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    1. The log file sent yesterday was that the FCC was low, not the SOC.
    2. The low FCC means that the FCC is not updated after the full charge, and the RM is also low.
    3. The SOC jump is when the discharge reaches about 67%, normal full charge and full discharge, and there is no feedback from customers at present.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    I'm waiting to hear back from star.

    A jump in SOC can indicate a jump in FCC since SOC = RemCap/FCC. Usually an FCC jump is from an increase in Ra resistance in the table, or other outside influence (current, temperature)

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello
    Looking at the document "SOC JUMP.log", the FCC has not been updated, and the RM is rising, resulting in an increase in SOC.

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    The FCC will only update under specific conditions, you can look at SLUA450 for the specific points the gauge will update FCC.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 605 points

    Hello,
    Is there a solution to the SOC jump problem? After I set RELAX_SMOOTH_OK to 0, the jump is slow, but it still jumps? Can you help find out the ultimate cause? Because of this problem, our products are out of stock

  • 0 in reply to Sunrain
    TI__Guru** 104905 points

    Hello Jingming,

    As mentioned before, it is the characteristic of this algorithm that it may not be able to gauge this chemistry with a max DOD error of 8%.

    I would recommend using the BQ4050 since it relies on coulomb counting more heavily instead of voltage.

    Sincerely,

    Wyatt Keller