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: Failure to assert FC flag and OCVTAKEN flag

Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQSTUDIO

I have a 6s 22Ah battery that I was attempting to run through a learning cycle. As far as I can tell, everything was programmed correctly other than the following:

Problems:

  • Many hours of waiting after either a full charge or discharge would never assert the OCVTAKEN.
  • At top end of charging, the FC flag would never assert inside the taper region either.

Things done correctly:

  • Newest firmware, proper chemistry as found with a successful GPC test
  • Proper pack config and thresholds were updated to reflect the battery as well as proper calibrations performed
  • Charge cutoff properly performed
  • Proper constant C/5 load for DSG
  • Properly followed instructions for Achieving a Successful Learning Cycle

Things done incorrectly:

  • Design Energy was set to an arbitrary value of 4755 Explanation: Due to a misunderstanding on how to use the parameter; I assumed 22000mAh * 3.7V * 6 cells and got 475568. Couldn't divide the value low enough with the Design Energy Scale so I just left the scale at 1 and divided the value down by 100 assuming that this was just used for the "Available Energy" output anyway.
  • IT Learning Config Registers (Max/Min Res Factor/Scale, Max Qmax Change) were set to the values for Non-Removable battery packs as shown in the datasheet because the BMS was intended to stay with the pack. While this was intentional, it may have prevented the initial learning cycle.

Changes that fixed the problem:

  • Design Energy set to 22000mAh * 3.7 / 3 = 27133
  • Design Energy Scale set to 3
  • IT Learning Config Registers set to values for Removable battery packs as shown in datasheet.

In the interest of saving some time, which of the above likely caused the problem?

When attempting to achieve a learning cycle for a new battery do you recommend setting the IT Config Registers to values for Removable battery packs?

If so, once the first learning cycle is complete can I then change these to the values for Non-Removable packs in the golden image when I go into production?

  • Hi Joshua,

    With respect to the difference between removable and non-removable, the tolerances are lessened for removable packs with the intention to allow for the replacement and relearning of a battery (same model, but brand new instead of aged) in the field.

    When performing the initial learning cycle, leaving the removable/non-removable values as default should be okay. Changing them should have no ill effect.

    Please ensure that FC Set = -1%. When running the learning cycle, make sure that IT is enabled and that the battery has adequate time to rest. Also ensure that the series value is set to 6 and that VOLSEL = 1 since you are using the external divider.

    Please also ensure that calibration has been performed.

    If errors persists, please attach a copy of your SREC (from before the test), gg.csv file (from before the test) and the log of the test for analysis.

    Sincerely,
    Bryan Kahler
  • Bryan,

    Thanks for the input! All of the things you mentioned were done correctly for the tests ( FC Set = -1%; IT enabled;  Adequate rest times; Num series cells to 6; VOLSEL = 1; Proper calibration; etc.)

    In fact the only things I changed that fixed this issue were the Design Energy settings and the IT Learning Config Registers as detailed in the original post.

    Rather than tie up test equipment trying to find which setting was the problem I was wondering if someone might know which of these two settings were causing problem with the learning cycle. 

    Is it possible that setting the Design Energy incorrectly could prevent assertion of the FC flag or OCVTAKEN flag during the initial learning cycle?

      Is it possible that setting the IT Learning Config registers to values that reflect Non-Removable packs could prevent assertion of the FC flag or OCVTAKEN flag during the initial learning cycle?

    • Joshua,

      Design energy should be properly set. Both non-removable/removable packs settings should work for learning.

      To ensure that the values are set properly, please follow the steps in section 8 of the datasheet.

      If errors persists, please attach a copy of your SREC (from before the test), gg.csv file (from before the test) and the log of the test for analysis.

      Sincerely,
      Bryan Kahler
    • Bryan,

      I tried to do a learning cycle on a 22Ah 6s battery while using the Non-removable pack settings here are the details:

      • Started with stock FW image
      • Updated to proper chemistry
      • Wrote relevant flash values (see .gg.csv file)
      • Calibrated current with a scaling factor of 4 (flash parameters appropriately scaled)
      • Had a fully discharged/rested battery
      • Started logging data
      • Sent IT_ENABLE 0x21
      • Sent RESET 0x41
      • Waited for OCVTAKEN
      • Began charging at C/2 rate and continued into taper region
      • FC never asserted even though   CHG Current Threshold < Average_Current < Taper Current for over 5 minutes

      .gg.csv file is from AFTER test unfortunately. I checked all the values with my spreadsheet and the only things that changed were the lifetime data so it should not be a problem.

      What prevented the FC bit from asserting?

      /cfs-file/__key/communityserver-discussions-components-files/196/22Ah_5F00_Scaled_5F00_Files.zip

    • Hi Joshua,

      For FC to assert with FC Set% = -1:

      1. During two consecutive periods of Current Taper Window, the AverageCurrent() is less than Taper Current AND
      2. During the same periods, the accumulated change in capacity > 0.25 mAh /Taper Current Window AND
      3. Voltage() is > Charging Voltage – Charging Taper Voltage. When this occurs, the [CHG] bit of Flags() is cleared. Also, if the [RMFCC] bit of Pack Configuration is set, and RemainingCapacity() is set equal to FullChargeCapacity().

      Sincerely,
      Bryan Kahler
    • Bryan,

      Thanks for the criteria for the assertion of FC! I have carefully attempted to meet all three of these requirements (as the data will show) which is why I am confused.

      This is the fourth system that I have designed for production using the BQ34Z10-G1 as the gauging device so I am fairly acquainted with the documentation on the part as well as how to perform learning cycles.

      I have looked over the settings as well as reviewed the data logs but have not been able to figure out why meeting the criteria for FC to assert results in FC doing nothing. Perhaps one of my settings is wrong?

      Thanks,
      Josh
    • Repeated the learning cycle again with taper current increased from C/100 to C/50. Learning cycle successful.

      Conclusions:

      • The parameter Min Taper Capacity in the datasheet and in bqStudio is displayed as units of mAh. However it seems that the true units are 0.01 mAh
      • A learning cycle is possible with IT Learning Config Registers set to the values for Non-Removable battery packs; The Ra table updates just fine during the initial learning cycle;

      Unknowns:

      • It is a mystery why FC never asserted with a taper current of C/100. The criteria for this were met:
        • During two consecutive periods of Current Taper Window, the AverageCurrent() is less than Taper Current: The AverageCurrent() was at 219mA and decreasing slowly during the taper region; Taper current set to 220mA; No problem here.
        • During the same periods, the accumulated change in capacity > 0.25 mAh /Taper Current Window: 0.25mAh / (40sec / 3600sec/hr) = 22.5mA minimum current necessary to meet this requirement; No problem here.
        • Voltage() is > Charging Voltage – Charging Taper Voltage; 25200mV > 25200mV-100mV*6 No problem here either.
      • It is a mystery why increasing the taper current from C/100 (220mA) to C/50 (440mA) fixed this issue. The data attached in my earlier post shows that I was doing things properly. I do not like loose ends like this but I have no more time to explore the issue.