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: DOD0 update wrong

Part Number: BQ34Z100-G1

Hello,

We try to implement the BQ34z100-g1 gauge for our large capacity multicell battery packs. There is an 8 cell (in series) 24v version and an 8 cell 12v version (2 in parallel, 4x in series). Cells are SE200 from CALB. The chemistry is determined using the TI chemistry tool in both cases and valid according to the tool.

On both batteries, the learning cycle was succesful, with learned status going to 6 and maxerror going to 1.  Also the RA tables were updated.

After the learning cycle, an extra charge / discharge cycle was performed. For the 24V version this cycle was succesful, for the 12V version it is not.

Digging through the logging data, i found that at the moment that the battery is fully charged, a TrueFCC update is done together with reset of DID0PassedQ etc.. The difference wrt the same log for the 24V unit is that the DOD0 is updated from 15922 to 30048 instead of 0. This update also results in a stateofcharge reading of 0 and the device does not recover from this.

The log of the failing charge is attached, also the parameter list with the used settings.

0755.second charge.log

bq5_first_discharge_after_first_charge.gg.zip

From other posts i found that the Design Energy has a wrong setting and Design Scale is 20 which should be limited to 10. Using current mode and not power mode I ignored these values. Is this of influence?

Other major difference is that the capacity is 20000mAh. Could this result in internal overflows of the various registers and calculations? Would scaling the current measurement and capacities further down help?

Thanks in advance for your help

Jacob

  • Hi Jacob,

    Thank you for the detailed post.

    Capacities up to 29 Ah should not result in internal overflows, assuming all other settings are valid.

    Please correct me if I'm wrong, but a cursory search indicates that with the CALB SE200 LiFePO4 Battery, capacity is 200 Ah, charge voltage is 3.6 V and terminate voltage is 2.5 V.

    With a 200 Ah capacity (200,000 mAh) per cell, current scaling could need to be applied with a current scale factor of at least 7 for an xS1P application, and a current scale factor of at least 14 for an xS2P application.

    For more information on current scale factor and high cell count and high capacity applications, please refer to this app note: www.ti.com/.../slua760.pdf

    Parameters in the gauge with units of A or W will need to be scaled by the current scale factor, as described in the app note above.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    Thank you for the quick reply. I have used the information you mentioned for configuring the gauge initially.

    In both cases the current is scaled x20. The result is a gauge capacity of 10000mA for the 8 cell 24v version (20x10000mAh= 200Ah). For the 400Ah 12V version the gauge capacity is 20000mA (x20 = 400Ah). The shunt and amplification is such that 625A corresponds to 125mV on the shunt input. Voltage reading is done via an external divider and the voltsel bit is set.

    Now trying to find out why the gauge calculates this strange DOD0 at the moment the charge cycle is finished. From the TI literature i find that de DOD0 is a function of OCV and temperature dependent on the Chemid. So far i tried 2 different chemids but the result is the same.

    But in both cases, right after the first charge after the succesful learning cycle, the DOD0 is updated from around 15000 to more than 30000.See sample 2030 in the log of the initial post.

    I cannot find out what the number itself means, but the result is that the SOC reading is set to 0, as well as the RC and FCC. As if the battery is deeply discharged while the battery voltage is at or above 8x the cell charge voltage. Also over time, this does not correct itself.

    As said, the only thing i found that i did not set correctly is the Design Energy as i thought it was of no influence. Could that be a reason for the gauge to do a miscalculation? Which other settings do influence this mechanism?

    Best regards,

    Jacob

  • Hi Jacob,

    Thank you for the update.

    The design energy scale and current scaling are two very different things. The current scaling is when you 'trick' the device into seeing a smaller current. For example, for a scale factor of 4 you will apply 4 A during calibration but set the 4 A actual as 1 A actual in the device. All other parameters in the data flash that are in units of A or W will need to be modified.

    Also, a learning cycle is required after making this alteration. SOC (% based) will report properly, but values with A or W read from the gauge will need to be scaled by the current scale factor on the host MCU.

    From the discussion above, it appears you have performed the steps above. The only issue i'm seeing immediately is that some of the other values in A or W in your gg.csv file have not been scaled with that x20 current scale factor.

    For example, default taper current is 100 mA. In your gg.csv file, it is set to 600 mA and with the current scale factor of 20 that would pan out to a 12 A taper, actual.

    If you want taper current set at 600 mA actual, please apply the current scale factor of 20 and set the value to 30.

    This will apply to all over values in the gauge with A or W.

    Please use a fresh SREC (puts the device into a state where IT has never been enabled), update the chemID (puts the device into an unlearned state) and update the values with the current scale factor applied, then run the learning cycle.

    Please let me know if the issue persists.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    Since the pack is 400Ah, the intention was actually to set the taper current to 12A ((600x20). The pack is charged with 0.5C = 200A, when it is full, the current drops very rapidly due to the very low internal resistance and sharp rise of OCV when nearly full. When the current is dropping, most chargers sooner or later step down in charge voltage ('float') effectively stopping the charge. This situation is however a valid full charge and should be recognized as such. We do not have control of these chargers, and on the other hand, we prefer a premature 100% soc reading above never getting to 100%.

    Also, i did not alter these settings after the learning cycle. With the settings in the file, the learning cycle was succesfully performed.
    Only when charging again after the discharge of the learning cycle, this strange phenomenon happens.

    I did this learning cycle with fresh SREC and 2 different chemID's (unlearned chip) twice with the rest of the settings as in the file, giving exactly this same result.

    Next week i will scale all current related parameters by 40 including the calibration, such that the capacity will be set to 10000mA and perform another fresh learning cycle as you indicated.

    However, besides the current scaling, i still am interested in the importance of the Design Energy and design scale. And whether you have ever seen a DOD0 jump like this before. If i know what can make it go to such a value and/or what is means, i may have a clue which other setting is false.

    Thanks and have a nice weekend

    Jacob
  • Hi Jacob,

    Design Energy and the design energy scale are utilized in power calculations, for example, when the device is in Mode 1. The parameters are configured on a 1SXP basis.

    So Design energy = design capacity * design voltage of a single cell / design energy scale value
    where
    Design capacity = design capacity of a single cell * number of parallel cells

    Which would change to the following with current scaling:

    So Design energy = design capacity * design voltage of a single cell / design energy scale value
    where
    Design capacity = design capacity of a single cell * number of parallel cells / current scale factor

    The current scale factor is applied first here and may obviate the need for a design energy scale value greater than 1 for some configurations.

    Sincerely,
    Bryan Kahler