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: RUP_DIS Flag asserting at C/5 DSG on learned pack

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

Designing a 22000mAh battery pack with bq34z100-g1

Expect up to 110A sustained currents as this is a LiPo pack for heavy octocoptors

Design procedure:

  • Designed, fabricated, and assembled PCB

  • Updated firmware to bq34z100_G1_v0_16_build_17.srec

  • Updated bqstudio with the latest chemistry options

  • Set the appropriate flash defaults in the bq fuel gauging chip for basic functionality

  • Determined a chemistry match by following the insructions for the GPCCHEM tool

  • Followed the charge, rest, C/10 discharge profile

  • Successfully obtained a sutiable ChemID of 1530 with Max DOD error of 1.63% and Max R deviation ratio 0.8

  • Instrumentation was performed with a Yokogawa WT310 power meter for optimal accuracy

  • Re-flashed bq part with stock firmware

  • Updated chemistry of bq part to 1530

  • Updated flash parameters of bq part with a current scaling factor of 4:

  • Taper current = 110mA (scaling factor of 4 so this equates to 440mA)

  • Min Taper Capacity = 6mAh (scaling factor of 4 so this equates to 24mA)

  • Cell Taper Voltage = 40mV

  • FC Set% = -1

  • CC Threshold = 5500mAh (scaling factor of 4 so this equates to 22000mA)

  • Design Capacity = 5500mAh (scaling factor of 4 so this equates to 22000mA)

  • Design Energy = 20159mWh ([21793; single cell capacity] / [4; scaling factor] x 3.7V)

  • Design Energy Scale = 1 (can’t scale up because max value in register is 32767)

  • VOLSEL = 1

  • RMFCC = 1

  • Number of series cell = 6

  • Cell terminate voltage = 3000mV

  • Dsg Current Threshold = 25mA (scaling factor of 4 so this equates to 100mA)

  • Chg Current Threshold = 25mA (scaling factor of 4 so this equates to 100mA)

  • Quit Current = 10mA (scaling factor of 4 so this equates to 40mA)

  • Qmax Cell 0 = 5434 (scaling factor of 4 so this equates to 21736mAh)

  • Calibrated voltage

  • Calibrated current with a scaling factor of 4

  • Performed a successful learning cycle by following the instructions

  • Started with a fully discharged and rested battery

  • Charged at C/2 until taper; FC was asserted and charging was stopped;

  • Relaxed 2hrs

  • DSG at C/10 until empty

  • Relaxed 5 hrs

  • Achieved learning status of 0x06

  • Ra tables updated appropriately

  • Created golden image

  • Saved .gg.csv file from above; set update status to 0x02, cycle counts to zero, lifetimes to defaults

  • A clean/default srec imported on the device

  • Chemistry updated on the device

  • Imported .gg.csv file to device

  • Calibrated voltage

  • Calibrated current with a scaling factor of 4

  • Saved this .srec as a golden image

  • Re-programmed bq part with this golden image, enabled IT

Validation:

  • See if the bq part updates the Ra tables with a C/5 DSG rate

  • Started with an empty, rested pack

  • Charged at C/2 until FC asserted

  • Relaxed 2hrs
  • DSG at a C/5 rate and watch Ra tables

PROBLEMS:

  • The RUP_DIS flag asserted during DSG at 84% SOC for some reason and remained asserted down to 0%

  • Note: After I noticed this I did end up bumping the DSG rate up to 1.3C for a few minutes to just empty the battery and then decided to resume at C/5 just to complete the test. Nonetheless the RUP_DIS flag asserted before this happened.

  • Subsequent attempts with this golden image have produced the same problem. I also tried to use the GPCRA0 tool (not including this data right now) to see if I could get better pre-programmed Ra coefficients but the problem persists.

I would like the bq part to work with 5C discharge rates but can't get it to behave with even C/5 rates right now. What would be the next steps to getting it to perform appropriately in this usage scenario?

Included are the golden .srec and the .gg.csv for the bq part before performing the test  and log data from the above test.

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

  • Hi Joshua,

    Please set CC Threshold to be 90% of Design capacity.

    Will need to send you an SREC that has been tweaked. Thank you for sending the files you have - it may take me until Tuesday to modify your SREC and send it back.

    With the modified SREC, you will repeat the test to see if the RUP_DIS sets during discharge again.

    What is the actual resistance of the current sense resistor on your board?

    Sincerely,
    Bryan Kahler
  • Bryan,

    Thank you for the correction on CC Threshold. I will make that change.

    Understood on the time needed to modify the SREC.

    Current sense resistance is 100 μΩ

    I am very curious.. What is the nature of the modifications being made to the SREC in order to make it work with this scenario?

    I look forward to testing it out whenever you have it finished.

    Thanks!
    Josh
  • Hi Josh,

    The issue may be caused by the extremely small current sense resistor. The datasheet specs a range between 5-20 mOhm recommended.

    The 0.1 mOhm current sense resistor is outside of datasheet ranges, and deadband parameters. This small value also reduces the effective range of the ADC as it is now scaled to detect up to 1250 A, with a voltage range of +/- 125 mV across SRN and SRP. A 1 mOhm sense resistor (also outside of datasheet range) can handle current up to 125 A. When the current sense resistor is decreased in ohmic value, the max and min detectable ranges are both shifted upwards.

    A larger sense resistor is recommended.

    I will modify the SREC so we may determine if negative values or charge accumulation are the reason for RUP_DIS asserting during discharge.

    Sincerely,
    Bryan Kahler
  • Hi Josh,

    Have you tested with a larger current sense resistor? Has increasing the resistance resolved your issue?

    Sincerely,
    Bryan Kahler
  • Bryan,

    Thanks for the info about the sense resistor. One of the challenges of this design was to fit the PCB under a plastic cover with limited thermal conductivity. Since there was no space for a heat sink the only choice was to prevent thermal production by using an extremely low value current sense resistor. At such high discharge currents, even a small amount of resistance is appreciable as 0.1mOhm dissipates 1W at 100A. The trade off with this low resistance was the addition of a coarse current sense granularity. This was considered acceptable since this device was likely to be used at currents ranging from 30 A to 100 A.

    The great unknown was whether or not the bq34z100-g1 would still be able to gauge and update appropriately in these higher current ranges as well as under heavy dynamic load changes (i.e. momentary full throttle on octocopter for maneuvering).

    It seems that running this part out of spec (small sense resistor value) is causing the RUP_DIS to intermittently assert. I have done two DSG/REST/CHG/REST cycles at 40A and 60A loads respectively and, as of now, have not observed the condition again but I would still have my doubts with going to production with this configuration.

    I can’t afford to dissipate 50W across an appropriately sized sense resistor (100A through 5milliOhms). Also, amplification between between a low-value resistor and bq part adds too much circuitry for board space to allow.

    Is there a possibility of modifying an srec file to accommodate such a low sense resistance or would that be asking the bq34z100-g1 to operate outside of its capabilities?

    Thanks,
    Josh
  • Hi Josh,

    Looking through the files, please try to verify the Ra tables with a C/7 discharge. Please send the logs if the RUP_DIS issue is seen at a C/7 rate as well.

    Sincerely,
    Bryan Kahler
  • Hi Josh,

    Haven't heard from you in a while. Hopefully no news is good news and the issue is now resolved. If not, please provide the information requested above and let us know the current state of the issue.

    Sincerely,
    Bryan Kahler
  • Bryan,

    I've been busy on other projects over the past couple weeks but I did manage to get the data you requested.

    RUP_DIS asserted again on this run. I have also noticed on the past two full discharges that OCVTAKEN takes a full 48 hours to assert even though the voltage stabilized as usual. I’m not sure if it is a related problem.

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

  • Hi Joshua,

    Thank you for the logs. Due to current loading it may take until the COB Friday to analyze these logs.

    Sincerely,
    Bryan Kahler
  • Hi Joshua,

    I see OCVTAKEN asserting at Sample 6887 in the logs, immediately after the 6.7 hour discharge to empty.

    Please send me your input for the gpcra0 tool so I may generate those constants.

    Sincerely,
    Bryan Kahler
  • Bryan,

    You are quite correct. I must have been mistaken about which log I was looking at when I made that observation.

    Here are the files for the gpcra0 tool:

    /cfs-file/__key/communityserver-discussions-components-files/196/2555.40A_5F00_GPCRA0.zip

  • Hi Joshua,

    Ran the gpcra0 tool and uploaded the values here:

    /cfs-file/__key/communityserver-discussions-components-files/196/3326.GPC_5F00_report.zip

    Sincerely,

    Bryan Kahler