BQ40Z50-R3-DEVICE-FW: Learning Cycle

Hello Jeremy,

It look like from your log file that the discharge is too great to qualify it for updates, this is most likely why the cycle failed to update to 0x06.

Some of the other common issues are not cycling 90% of the design capacity during the learning cycle and setting the following parameters in a different order: 

Charge Term Taper Current > Chg Current Threshold > Quit Current.

You can reference this document for more specifics: https://www.ti.com/lit/an/slua903/slua903.pdf

Sincerely,

Wyatt Keller

Hi Wyatt,

Thank you for your prompt response!

I will try again using a lower discharge rate.  I have used C/4, but will reduce to this to C/7.5 as it is mid way between the recommended C/5 and C/10.

Regards,

Jeremy.

Hello Jeremy,

No problem! I hope this resolves your issue.

Sincerely,

Wyatt Keller

Hi Wyatt,

Unfortunately, the issue appears to be ongoing.

Following charge to set FC, I ran another discharge at C/7.5 and despite the grid point updates occurring, FD setting, VOK clearing, REST setting and over 6.5 hours of relaxing, there is no QMAX update and LStatus remains at 0x05.

Regards,

Jeremy.

LearningCycle2.zip

Hello Jeremy,

Another condition must not be getting met, let me check your logs tomorrow and I will get back to you then.

In the mean time I would double check the conditions in the document I linked to make sure you are meeting all of them.

Sincerely,

Wyatt Keller

Hello Jeremy,

Did you use the GPCCHEM Tool to obtain your ChemID? Usually if the LStatus fails to change to 0x06 it is due to a poorly matched ChemID.

From your last log, it doesn't seem that you logged all of the learning cycle. There also seemed that there were some communication errors and a measurement error. During the learning cycle, are you charging at C/2? 

Also, I noticed that you selected Constant Power as your Load Mode configuration, and I believe there's a mistake in your design capacity cWh which is used in your load configuration. Based on your mAh and mVh, it should be 38400-cWh instead. What battery-pack configuration are you using?

Best Regards,

Luis Hernandez Salomon

Hi Wyatt,

I have had a closer look at my first Register Log.  It appears that 2.9 hours into the relax after FD (line 27472), REST sets indicating the OCV Reading is taken, RDIS clears indicating Resistance Updates are enabled, but unfortunately VOK also clears, indicating no DOD saved and QMax update is not possible.  Rereading the Initial Qmax Update Criteria (SLUA903), I'm confident that Temperature, Delta Capacity and Voltage are satisfied (OCVFR never sets), but I'm puzzled by the Offset Error criteria. 

Firstly, do all of these criteria apply to both the first and second updates?  Including "Initial" in the title casts doubt in my mind, but it does not appear in SLUUBU5A, so I'm assuming it does.

"Offset Error — If offset error accumulated during time passed from previous OCV reading exceeds
1% of Design Capacity, update is disqualified. Offset error current is calculated as Coulomb Counter
Deadband/sense resistor value."

For this calculation, is "Coulomb Counter Deadband" the value contained in DF.Calibration.Current Deadband.Coulomb Counter Deadband?

If so, I assume that both this value (and the sense resistor) would be fixed, so how would Offset Error accumulate?

Is there an Offset Error register that can be inspected? 

I am using a BMS with 0.25mΩ sense resistor to accommodate very high discharge currents - could this be impacting drift?

Regards,

Jeremy.

Hi Wyatt,

I just tried out the GPCCHEM Tool and the report recommended a Chem ID close to what I was using, which is certainly encouraging, but I'll try again once I have a new log file that adheres to the C/5 to C/10 rate as the report also identified that the four hour rate I used was too high. This is a fantastic tool - kudos to the developers!

I use a charge rate of C/4, but I understand this is acceptable (?).

Well spotted on the cWh capacity I had mis-configured - it was indeed out by a factor of ten - thank you very much.

This has wide ranging implications of course, starting with the need to adjust my scaling factor from 4 to 5 as the Design Capacity for this gauge has an upper limit of 32767mAh / 32767cWh.  This meant I needed to revisit and adjust all capacity and many of the current based parameters.

Hopefully Design Capacity is the main cause of the problem and I'll leave a comment here once I have completed the learning cycle with the new values I am using.  Perhaps this also explains why the NSFM (Negative Scale Factor Mode) flag was set during discharge and why OC was being set during charge.

Regards,

Jeremy.