BQ40Z80: Qmax not updating in field after seemingly valid rest cycle

Hello Christopher,

The best reference for a learning cycle or Qmax updates is SLUA903: e2echina.ti.com/.../0827.7367.Achieving-the-Successful-Learning-Cycle.pdf

You should cycle at least 37% DOD and let the battery rest at each point while keeping the temperature within the 10DegC to 40DegC.

Are you able to use bqStudio to log the data so we can see all the registers to confirm this is temperature dependent?

Sincerely,

Wyatt Keller

Hello Chris,

The temperature doesn't seem to be the disqualifier based on the log you provided. I did noticed VOK didn't change from 1 to 0, so Qmax wasn't updated. Can you examine the charge accumulation on charging to ensure it's > 37% of Design Capacity. You didn't specify what your design capacity is set to.

Hi Wyatt,

Yes, we follow this procedure and have executed many field learning cycles with no issues, where the Qmax updates and MaxError reduces.  Almost always we see Qmax reduce to 1% after rest-after-charge, though we do also provision for a rest period after discharge if the max error remains above 1%.

The expectation is that Qmax will update after charging at least 37% DOD and resting, which in this case was true.  With 8% error we will not attempt a field update unless the starting SOC+error < 50%.

The attached log is from our application software, but we do log many more register values which I did not include but can provide if needed.  Which ones are you looking for specifically?  My understanding is that if Qmax update is disqualified that VOK will clear.

Specifically, can you tell me if Qmax update is disqualified if the temperature EVER goes out of bounds, or only if the temperature is out of bounds when the OCV reading occurs?  During this cycle, the temperature was out of bounds before the first rest, and rose above 40 during charge, but the REST flags were still set and VOK indicated things were as expected.

Best,

Chris Churavy

Also can you provide the gg.csv file or answer the following.

• Design Capacity?
• Number of series cells?
• Charging voltage
• Term Voltage
• Chem ID #

Please note if any of the cell voltage is in the flat region Qmax wouldn't update as well.

Hi Damian,

The design capacity in this case is 4900 mAh.  The log starts at 1382 and finishes at 5121.  Even with the max error, this is much more than 37%.

I've attached a copy of the log with RemainingCapacity and FullChargeCapacity included.

We previously set VOK going to 0 as a condition for accepting the field update, but it never seemed to change reliably even though the MaxError would reduce.  As I understand the other indicator is Qmax toggling.  The REST flag sets once the conditions are right and OVC is taken, so we've been using this flag and waiting 10 seconds to make sure any updates happen.  This log is the first evidence that this method may not be foolproof :)

Best,

Chris Churavybattery_log_w_capacity.csv

Hi Damian,

Design capacity = 4900mAh

Number of series cells = 5, 2 parallel

Charging voltage = in the log, but CV is 21V.  We use a simple CC/CV profile with CC ~0.6C

Term Voltage = 21V

Chem ID# = 2127

Regards,

Chris

Hi Damian,

Unfortunately the log does not contain OCVFR, but your explanation makes this the likely culprit.

If the OCV reading were invalidated, I would expect VOK to clear when starting to charge, but this was not the case.  Do you know why this might be?

Thanks,

Chris