BQ40Z50-R1: During the production process, it was detected that SOC jumped to 0.

Hello,

If possible, can you please share a log file along with the .gg file of the gauge settings during the SOC drop? This will give us a better idea of what is occurring within the gauge at this time.

Regards,

Anthony

This is the GG file for exporting SOC hops.CN071-SOC跳0-20240821.gg-A248FE0001058.csv

This is the GG file for exporting normal machines.CN071-正常-A248EF0001106.gg.csv

Hello,

Thank you for sending the .gg file, we will begin looking into them.

If possible, do you have a log file depicting the SOC drop to 0 we can look into?

Regards,

Anthony

No log files were recorded for the sudden drop of 0.Because after producing the battery, when reading the interior of BQ40Z50-R1, it was found that the normal voltage should correspond to a SOC of 50% -60%, but the SOC actually dropped to 0.

Hello,

Can you please confirm that the Terminate Voltage for the device showing this issue is properly set? Also, can you please confirm that a learning cycle was properly accomplished for this cell?

How was the chemID chosen for this application? Was the GPCCHEM tool used?

Regards,

Anthony

All of the above can be confirmed to be correct.

We have exported the GG files of 4 prototype SOC jumps to 0 and compared them with the GG files of normal machines. The highlighted red part of the attachment is different from the normal machine. Could you please see if you can identify any abnormal issues? Additionally, there is an attachment containing the original GG file (without any testing or aging).CN071-正常和异常对比.gg.csvCN071-2024620-seal（原始）.gg.csv

In addition, we also want to know the logic behind the sudden SOC jump to 0 of the BQ40Z50-R1 chip, and what conditions would cause this phenomenon to occur?

Hello,

shenzhiwei said:

We have exported the GG files of 4 prototype SOC jumps to 0 and compared them with the GG files of normal machines. The highlighted red part of the attachment is different from the normal machine. Could you please see if you can identify any abnormal issues? Additionally, there is an attachment containing the original GG file (without any testing or aging)

I do not believe the sent file has the highlighted section, can you please confirm the sent file?

shenzhiwei said:

In addition, we also want to know the logic behind the sudden SOC jump to 0 of the BQ40Z50-R1 chip, and what conditions would cause this phenomenon to occur?

There are a few conditions that could cause this drop, such as the terminate voltage being set incorrectly, the chemID not being a proper choice for the cell, the gauge operating in extreme temperature without temperature optimization, etc. However, it is difficult to determine a root cause in this case without a bqStudio log file depicting the situation, since this would allow us to look directly at the gauge registers when this situation occurs.

Regards,

Anthony

The data inside includes GG files for 1PCS normal machines, GG files for 4PCS abnormal machines, and GG files exported from 1PCS abnormal machines after re aging (the number of cycles is still 0 after re aging). The red part is marked as the difference between the GG files of abnormal machines and normal machines.CN071-正常和异常对比.gg.xlsx7356.CN071-2024620-seal（原始）.gg.csv

Hello,

Thank you for clarifying, we are able to see the red marked sections now. Regarding these sections, most of their values do not alter far enough from the normal .gg values that I believe would cause this issue. The Ra Table values have been updated, however they are still close to the normal Ra table values.

One section that stands out is the 6 CUV events that take place on the second abnormal .gg pull:

Is it possible to receive a bqStudio log file of the gauge when the SOC drop occurs? This would give us a better idea of what is causing the drop.

Regards,

Anthony

We found that the Ra Table values of the four abnormal batteries are the same as the original data (unaged) Ra Table values. In addition, yesterday we performed a reset action using one of the abnormal zero jump batteries, and the SOC was restored normally, corresponding to the capacity. However, when we tried to charge and test again, we found that as the capacity increased, the SOC of this abnormal battery pack did not increase or change, and the SOC value remained constant. We now suspect that the BQ40Z50-R1 chip is damaged. Have you encountered any similar cases here?

We tried flashing the program again and the chip was able to resume normal operation. But it is impossible to confirm whether the same risks still exist, and it cannot be simulated and reproduced.

Hello,

Can you please confirm whether there are any protections being triggered when the gauge is in the 0% SOC state? When the charge test is implemented, can you please confirm that the FETs are active and the current is actively being correctly read by the device?

Regards,

Anthony 

It will trigger protection, and the attachment is the discharge aging data of the abnormal battery (when SOC is 0), which can be seen with current display.

CN071-SOC跳0-老化第二步18A放电（放电老化）.xlsx

Hello,

Thank you for sending the log file, I believe one of the issues is coming from the MaxError being 101%, has an extended period happened where there has not been a Qmax update within the gauge before this log file?

Regards,

Anthony

Yes

Hello,

Regarding the Qmax updating, below list the conditions that the gauge will invalidate the calculated Qmax update:

Looking into the log file, the gauge is within the temperature range other than after the second discharge, where the gauge temperature is above 40. Can you please confirm in the relax period after the second discharge the temperature is less then 40?

Regarding the voltage, if you share the .srec file of the gauge we can confirm whether this condition is being broken.

Regards,

Anthony

The ambient temperature of the battery pack is at 25 ℃. During aging discharge, there is a section of the battery cell surface with a high temperature at the end of the discharge. However, after stopping the discharge, the temperature can be confirmed to be below 40 ℃.

Hello,

Today is a national holiday. We will get back to you later this week.

Regards,

BMS Apps Team

OK

Hello,

If possible, can you please share the .srec file of the device so we can check if the other conditions are being broken?

Regards,

Anthony

Is it a. rec file exported by an abnormal machine? Or is it a production. rec file?

Hello,

The .srec can be pulled from the device using the bqStudio Firmware Update page and pressing the button below:

Regards,

Anthony

Abnormal machine exports .srec file:CN070 异常机子.zip     Mass production machine subroutine.srec file:CN070 量产机子.zip

Hello,

Is the Mass production machine .srec of a gauge in a sealed state? If so, please share an unsealed version of this so we do not need to request the unseal keys if they are changed from the default.

Regards,

Anthony

the Mass production machine .is srec of a gauge in a sealed state；CN070-UNSEAL.zipCN070-UNSEAL.gg.gg.csv

Hello,

Thank you for sending the .srec. Looking into the previously sent log file of the discharge, it seems like the gauge never enters the rest state where the cell is in a truly relaxed state. For a Qmax update to occur, the gauge relies on two different OCV measurements taken during rest periods. Would you happen to have a charge -> relax -> discharge -> relax cycle in a log file so we can take a better look into why the gauge is not completing the Qmax update for an extended period?

Regards,

Anthony

As mentioned earlier, one machine has undergone aging charging and discharging cycles, but the number of cycles has not been updated. The attachment is a comparison of normal machine GG files, abnormal machine GG files, and aging GG files of abnormal machines on the same platform.5342.CN071-SOC跳0-老化第二步18A放电（放电老化）.xlsxCN071-异常机子重新充放电老化.gg.xlsx

Hello,

Regarding the number of cycles, I believe this is coming from the abnormal device not properly seeing the amount of passed charge that is occurring at this time. The cycle count relies on the cycle count percentage, which is the amount of passed charge during the discharge that is needed to increment this value. In the attached .gg file, this is currently at 90%, where it seems like the device is not seeing the passed charge.

Regards,

Anthony