• State TI Thinks Resolved
  • Locked Locked
  • Replies 27 replies
  • Answers 10 answers
  • Subscribers 64 subscribers
  • Views 4784 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ34Z100-G1: SOC=0 issue

Matteo Rigamonti
Expert 1170 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: GPCCHEM, GPCRA0, BQ34Z100, BQSTUDIO

Good morning,

I'm using a BQ34Z100-G1 for monitoring a 1S5P Li-ion battery pack.

Sometimes it happens the SOC value falls to zero, while all other working parameters remain on a correct value (and voltage, for example, is at a value not compatible to SOC=0). When it happens, sometimes after few hours the situation automatically return to correct value, but some other times the SOC remains at 0 and the only way to recover the situation is to disconnect and reconnect the battery (also a reset of BQ34Z100-G1 does not work).

I've read in the post "BQ34z100-g1. SoC Error" the problem can be related to "cell terminate voltage" configuration parameter. I tried to investigate about such a parameter and it could be the cause: increasing such a value, the problem is more frequent, while reducing such a value the problem seems to disappear. Is there any other cause for this SOC=0 issue?

Moreover, how it is possible to force a reset of the SOC estimation algoritm and to let the SOC to restore to the correct value when the SOC=0 situation happens?

Thank you in advance for any support

Best regards

Matteo

  • 0
    TI__Mastermind 25955 points
    Hi Matteo,

    SOC falling to 0 can happen for many reasons. In the bq34z100-g1 SoC Error post, found here: e2e.ti.com/.../627092 (please correct me if this is not the post you are referencing), the cause of the SOC drop was a large current spike that caused voltage to sag at the bat pin and drop below the terminate voltage set in the device. The recommendation for this particular case was to either add capacitance to the bat pin to prevent voltage sag from the heavy load or to reduce the terminate voltage.

    Now, for your particular case:

    When the voltage drops below the terminate voltage, SOC is set to 0.

    The gauge will run an FCC simulation when you reset the device either by removing and reattaching the cells, or by sending the reset command via I2C. The FCC simulation will estimate the capacity and SOC based on the OCV curve set in the device (this OCV curve is from your chemID).

    To restore the correct value:

    By resetting the device (sending the reset command and/or removing and reattaching the cells), the DOD point in the device will be cleared. New DOD points will be required to allow Qmax to update after the next qualified charge/discharge cycle of the Li-ion pack.

    To prevent the issue:

    Please ensure that the cell termination voltage is not set artificially high and is set to the actual value. Also ensure that the pack is properly calibrated.

    If the issue persists after taking these steps, please let me know!

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1170 points
    Hi Bryan,
    thank you very much for your help.
    Yes the post you referenced is correct: I started from it for investigating about my issue and it seems that the behavior I have is that. But I'm not completely sure, so if you have some other reason to point out for the SOC that fall to zero, please point them out, so I can try to investigate also about them. In fact in my application it sounds strange there are some important voltage dips that can temporary reduce the voltage on BAT pin.
    (I have to say that I'm using a single series cell configuration for my battery pack, but I prefer to activate the VOLSEL bit in Pack configuration register and using an enable MOS on voltage divider network for reducing any leakage from the battery. I don't know if such approach can create some problem on voltage reading on BAT pin.)

    I've selected the proper chemID: my battery model is exactly in the database. So I expect to obtain a good SOC value when I perform a reset also via I2C, accordingly to your explanation. But it doesn't happen. so far I've found two ways for restoring the SOC value after a fall to zero:
    - disconnect and reconnect the battery pack from the BQ34Z100-G1
    - first change (reduce) the "cell terminate voltage" value and, only after that, send a reset command via I2C (i.e. a simple reset without changing the cell terminate voltage doesn't work)
    The problem is that for the end user it is impossible to disconnect and reconnect the battery for restoring the SOC issue, so I have to find a definitive way to fix the problem or to restore any wrong situation only by means of I2C communication.

    Anyway I've selected a proper cell termination voltage value (3000mA, but I can also try to reduce it a little) and the gauge have properly been calibrated.

    So I have no clear ideas for definitively fixing this issue.

    Thank you and best regards

    Matteo
  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    Hi Matteo,

    For hardware:

    With a single cell source, to eliminate your MOS circuit as a source of failure, try using the internal voltage divider. If the device operates properly with the internal voltage divider (ratio of 5:1) debug should continue with the MOS circuit.

    What is the turn on time for your MOS circuit? If the ADC reading is taken when the device is in the linear region and not saturation, improper voltages may be observed.

    For gauging:

    Although the chemistry model is exactly in the database, it is possible that the values differ. If the test above fails for the internal divider as well, the chemID is a likely culprit. Please log a charge-rest-discharge-rest cycle at room temperature and create a config.txt file to upload to the gpcchem tool for chemID verification. The tool and its user manual may be found here: http://www.ti.com/tool/gpcchem . Then, program the device with the chemID determined by the GPCCHEM tool, perform a learning cycle, and then test SOC again.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    thank you for your further answer.

    I've found an error in the BQ34Z100-g1 configuration. As I wrote, I'm using a voltage divider with the MOS as enable:

    But in the "pack configuration" register the flag "VOLSEL" is not set!

    Can this mistake create any syncronization issue and so any reading error that can lead to the SOC=0 problem?

    if yes, we've found the culprit and I apologize for the error. If not, I will go ahead by following your suggestions.

    Thank you again and best regards

    Matteo

  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    Hi Matteo,

    If Volsel is not asserted, the device also utilizes the internal divider, which is a 5:1 divider. Please set Volsel = 1 to use only the external divider.

    This appears to be the root cause. Please let me know if any other issues arise!

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    the additional voltage divider inside the BQ34Z100-G1 should already considered and compensated through the calibration process, right? So it seems strage to be the root cause of the sporadic issue (SOC jumps to 0) I have in my application. In your previous post you mentioned the possibility to have problems due to mismatch between voltage divider MOS and voltage on BAT pin or its reading by the BQ. Can that be influenced by the configuration error (VOLSEL=0 with an external voltage divider with enable MOS)?

    Moreover, just in case I need to restore the proper SOC value without removing the battery, why the reset command via I2C doesn't work? Is there any other way?

    Thank you again for your support and best regards

    Matteo

  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    Hi Matteo,

    Please test using the internal divider only as suggested above and let me know how the test goes so we can compare results.

    The SOC value was designed to be reset when a cell was replaced. SOC should not have to be reset in normal operation. We can continue down this path, but I'd prefer to root cause the SOC issue first so this workaround becomes obviated.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    TI__Mastermind 25955 points
    Hi Matteo,

    Haven't heard back since this answer was suggested - hope the issue is resolved. If not, please let us know.

    If this answer resolved the issue, please hit the green 'resolved' button to help improve question/answer searchability on the forums. Thank you!

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    sorry for my late answer, but in the meantime here in Italy we were on holidays (August is the holiday month for Italians...) and I tried to make some more time consuming tests (I performed several charge and discharge cycles on several samples) for finding the solution.

    Unfortunately I can't apply any change to the VOLTSEL flag because:

    • if I disable the internal voltage divider, the BAT pin voltage is too high, out of acceptable range)
    • i can't remove the external voltage divider because I have several devices already working on field and I can't apply a recall campaign

    So currently the only way to fix the issue is to reduce the "cell terminate voltage" at the lowest value compatible with battery cells.

    My tests are confirming such a work around will be effective, but I would like to ask to you if you see any other critical point is still present if I change only the "cell terminate voltage" parameter.

    If it was necessary for your evaluations, I can take a sample I have in my lab, remove the external voltage divider and try to test it with VOLTSEL=0. Please let me know. But it will be only a lab test, not the definitive solution, as mentioned above.

    Thak you again and best regards

    Matteo

  • 0 in reply to Matteo Rigamonti
    TI__Genius 14985 points
    Hi Matteo,
    I would like to suggest one other possible root cause to investigate.
    You say you used the appropriate chemID since your battery model is already in the database.
    However, once you programmed the chemID did you perform a learning cycle OR use GPCRA to optimize the Qmax and Ra values for your actual battery and its configuration? Or did you just program the chemID and begin testing immediately?
  • 0 in reply to dMax
    TI__Mastermind 25955 points
    Hi Matteo,

    Support will continue for this question in this new thread you have posted: e2e.ti.com/.../724833

    Sincerely,
    Bryan Kahler
  • 0 in reply to dMax
    Expert 1170 points
    Hi dMax,
    I performed a successfully learning cycle for creating the golden file I'm currently using.

    Matteo
  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    the thread you have linked is related to another topic. This is the correct one:

    https://e2e.ti.com/support/power_management/f/196/p/713731/2674484#2674484

    Matteo

  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    Hi Matteo,

    Now that the learning cycle has been performed, are you still seeing SOC drop issues?

    If so, please send a gg.csv file from before the test, a gg.csv file after the test, and a log of the test in which you see the SOC drop issues.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    the learning cycle was already performed since the beginning of this thread.

    Recently I was confident to have fixed the problem by reducing the Cell Terminate Voltage value, but, unfortunately, the problem arose in another way: when the battery is full charged, removing the charger for a couple of hours and connecting the charger again, it can happens the SOC falls to zero. In that case, after removing the charger and waiting for few hours, the SOC returns to the correct value (around 100%).

    I can attach a .gg file when the SOC falls to zero just for checking.

    I have no idea about this issue... Something wrong in my BQ34Z100-G1 configuration?

    If you have any suggestion, please let me know.

    Thank you and best regards

    Matteo

  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    Hi Matteo,

    Thank you for the gg.csv file. Please also send a full log of the event with all of the columns enabled.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    I've repeated the test and fortunately in a few minutes the entire sequence happened. In the attached file you can find:

    BQ34_soc0_20181004_start.gg.csv : configuration file at the test start

    BQ34_soc0_20181004_start.png : registers screenshot at the test start

    BQ34_soc0_20181004_error.gg.csv : configuration file immidiately after SoC jump to 0

    BQ34_soc0_20181004_error.png : screenshot immidiately after SoC jump to 0

    BQ34_soc0_20181004_stop.gg.csv : configuration file after SoC jump back to 100%

    BQ34_soc0_20181004_stop.png : screenshot after SoC jump back to 100%

    BQ34_soc0_20181004.log : log file

    I hope it can be useful!

    Thank you and best regards

    Matteo

    BQ34_soc0_20181004.zip

  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    HI Matteo,

    Thank you for the files. I will analyze these files and provide an update by end of day Tuesday.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    TI__Mastermind 25955 points
    Hi Matteo,

    I apologize for the delay in response. We are currently at the the BMS Deep Dive and our schedule has pushed back. I will provide an update to this post by EOD Friday.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    TI__Mastermind 25955 points
    Hi Matteo,

    A few things to modify:

    Please change design energy scale to 10 and modify design energy correspondingly. Design energy should not surpass 32767.

    If this does not resolve the issue:

    Please take another log of the event but at 1 second intervals and again provide the gg.csv file from the start and end of the test. Please also send the SREC.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    the original settings were "Energy Scale"=2 and "Design Energy"=32375, so in agreemen with constraints (from datasheet: "The value of Design Energy Scale can be between 1 and 10 only"). Why they were wrong?

    Anyway, I changed them accordingly to your suggestion ("Energy Scale"=10 and "Design Energy"=6475), but the problem still persists.

    Below you can find new acquisitions:

    BQ34_soc0_20181018_start.gg.csv : configuration file at the test start

    BQ34_soc0_20181018_error.gg.csv : configuration file immidiately after SoC jump to 0

    BQ34_soc0_20181018_stop.gg.csv : configuration file after SoC jump back to 100%

    BQ34_soc0_20181018.log : log file

    You can find also the readme.txt file with the sequence of operations we made for forcing the problem to happen. It seems it appeared after switching the BQ34 back to the SEAL mode...

    Thank you for your support.

    Matteo

    0310.BQ34_soc0_20181018.zip

     

  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    Hi Matteo,

    Thank you for the updated logs. I will analyze these and provide an update by EOD Thursday.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    TI__Mastermind 25955 points
    Hi Matteo,

    I apologize for the delay - due to loading am still processing the logs, will update by EOD Friday (tomorrow).

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    TI__Mastermind 25955 points

    Hi Matteo,

    Please set fc set % = -1. Ensure that charge is terminated after the FC bit is set and allow the cell to rest before beginning your discharge.

    Please try raising Cell Term V Delta to 800 to initiate fast scaling earlier.

    How did you get the values for Ra0? Was the GPCRA0 tool used? The value for Ra0 should be approximately equal to that of Ra1. Please copy the value for Ra1 to Ra0 and rerun your test.

    How did you determine your chemID?  What is your chemID number?

    Sincerely,
    Bryan Kahler

  • 0 in reply to Bryan Kahler
    Expert 1170 points

    Hi Bryan,

    thank you for your support.

    We tested the solution with fc set % = -1 and Cell Term V Delta = 800, but it didn't work. Or better, by setting Cell Term V Delta = 800 the problem of SOC jumping to 0 was immediate after such setting and sealing the BQ34Z100.

    When we added the further correction of Ra0 forced equal to Ra1, we obtained good results: SOC jumps disappeared!

    We try also to restore the original values of fc set % and Cell Term V Delta and the solution of Ra0=Ra1 still works. So I would like to ask you if it can make sense to apply only such latter change: Ra0= Ra1.

    If possible, I would also better understand the meaning of the Cell Term V delta parameter, in order to find the proper value for that (also for other applications).

    By the way, we run a learning cycle and created the golden file (where Ra0 value seems to be wrong) accordingly to SLUA777 and by using the BQStudio for exporting files. Moreover, we found in the ChemID database exactly the same model of cell (INR18650 MJ1) we are using in our battery pack: number 2059.

    Thank you again and best regards

    Matteo

  • 0 in reply to Matteo Rigamonti
    TI__Mastermind 25955 points
    Hi Matteo,

    I'm glad to hear the Ra0=Ra1 solution provided acceptable results. The increase of Cell Term V Delta was to begin fast scaling sooner, instead of 200 mV above terminate voltage. If the gauge is under a heavy load, it may need the range increased so the SOC is more accurate as the gauge nears terminate voltage (as the gauge is discharging more quickly decreases voltage more quickly than a lighter load).

    Sincerely,
    Bryan Kahler