BQ27531-G1: golden image not working well on target board

After running another cycle, behavior seems to be getting worse.  Plot below shows "True SOC" as reported by the gas gauge vs computed "True SOC" .  I am computing true SOC as 100% - Qpass / QpassFinal.  QpassFinal is 7041 mAh, the total passed charge across the discharge.  Current is not constant but doesn't vary much across the discharge.  Current starts at -769 mA and ends at -887 mA.  Discharge is from fully charged to my system minimum voltage of 3.5 V

Remaining Capacity also behaves poorly.  Full charge capacity was reported as the same value, 7309 mAh, through the entire discharge.  However, the next morning when I applied external power to charge the battery, FCC was reported as ~1600 mAh, which then increases as it charges.  Unfortunately I don't have visibility into when it jumps down.  While discharging our system is polling on the I2C bus so I can't have bqStudio monitoring it.  Once voltage reaches 3500 mV my system shuts off and my log stops.

Here is plot of RemainingCapacityFiltered() reported by gas gauge, vs true Remaining Capacity  computed as (QpassFinal - Qpass)

  For reference, here are plots of current and voltage as reported by gas gauge.  These look reasonable:

Dominik,

Thanks for the reply. Sorry to be slow to get back to you.  I was out of the office Monday and Friday.

Please see my responses below.  I have changed Design capacity back to the nominal battery pack capacity, and am going to do some testing on the dev board to eliminate any effect my target hardware has on this issue.  Once I have confirmed the golden image works on the TI dev board, I will move back to my target hardware.

>> I suspect this problem has something to do with executing the learning cycle by discharging the battery to its limit of 2.5 V, then changing Final Voltage and Terminate Voltage to my system minimum voltage of 3.5 V.

> Changing from a lower to a higher voltage is usually not an issue. The objective of the learning cycle is for the gauge to learn QMax and Ra. And that requires that you cover the whole depth of discharge range of the battery (a good approximation is a full charge to the max. charging voltage with a low taper current and 3000mV with a C/5 current).

During the learning I discharged to a voltage of  2500 mV with a C/5 current.  I have four cells in parallel, each with a typical capacity of 3350 mAh (link below to PDF file where I got these specs from).  For design capacity I am using 13400 mAh which is what the battery pack is labeled as.

Battery pack: https://www.batteryspace.com/custom-li-ion-18650-battery-3-6v-13-4ah-48-24wh-3-5a-rate-2x2e-e-ncr18650b.aspx

Component cells: https://www.batteryspace.com/prod-specs/NCR18650B.pdf 

> If you then change the terminate voltage from 3000mV to 3300mV, it will be compatible, because all you do is effectively prevent the cell from discharging all the way to DOD = 1.0. So that's not a problem at all.

When I changed terminate voltage from 2500 mV to 3500 mV, I did not have any problems.  I went through 7 discharge cycles after changing terminate voltage and all values reported by the gas gauge seemed reasonable.  However I did notice one odd thing - Qmax never changed after I changed the terminate voltage.  Prior to that, it was updating after charging and discharging, staying close to the design capacity.  The final Qmax  update was to 13142 mAh.  It stayed at that number through all 7 discharge / charge cycles where terminate voltage was 3500 mV.

>  2500mV seems extremely low for a lot of chemistries. Unless you know that the ChemID goes all the way down to 2.5V, I wouldn't do this.

The component cell spec sheet linked to above states "Minimum Voltage, 2.5 V".  So I discharged the batteries down to that level during the training cycle, as my understanding for the instructions for the learning cycle were to discharge to the battery minimum voltage.  The ChemID was obtained using GPC tool.  From the report I got back:

  Best chemical ID : 2086 Best chemical ID max. deviation, % : 2.04

This ChemID is for Panasonic NCR18650A.  Our component cells are Panasonic NCR18650B.  I don't know what the difference is, but I figured I should go with the ChemID produced by GPC.  Someone worked on this before me and ran into similar problems that I am seeing.  He used the ChemID for the component cells, but as our battery pack has some protection circuitry in addition to the cells, I was hoping the ChemID being non-representative of the battery pack as a whole was part of our problem.  

> Likewise, 3500mV is high for Terminate Voltage (because that will be above the voltage knee of many chemistries). This can lead to inaccurate capacity simulations, depending on chemistry.

I am not familiar with the hardware design so can't speak to why the voltage is set at this level, but I did confirm this is the correct limit.

>> I also changed Design Capacity to 6000 mAh (about what I expected to get out of the battery under worst case current draw) 

> This is a common mistake. Do not change Design Capacity. The gauge uses this for C rate based calculations and this should be set to the nominal capacity as per the cell's manufacturer. It must not be adjusted to what you want to get out of the cell. It's intended to be the nominal capacity and constant.

> The gauge will calculate FCC (full charge capacity) based on your charge termination and terminate voltage and load prediction settings so there is no need to manually adjust this capacity. At best, you will confuse the algorithm for any calculations it performs relative to Design Capacity and at worst you'll work counter to the adaptive nature of the algorithm.

I changed this per the instructions in slua903 Achieving the Successful Learning Cycle.  In section 2.1 it states: "After the learning cycle completes, [Design Capacity] can be adjusted to the actual amount of capacity extracted under the application's real conditions".  For my applications, with worst case current draw, this is about 6000 mAh.  In my testing I got about 7100 mAh, running at the low end of our predicted current draw.

I did have to adjust the Charge Currents to account for the change in Design Capacity, to get the charging current I wanted.  For my future testing I am running with your recommendation of setting this based on the nominal capacity of the battery pack, which is 13400 mAh.  I set CC Threshold to 90% of this, 12060 mAh.

>> Qmax changed to 7800 mAh after my first discharge / charge cycle.

> This must not happen. QMax = passed charge / change in DOD. Passed charge = coulomb count. If your sense resistor is correct (and CC Gain is correct) and if the ChemID is correct, then QMax won't just change to 50% of the learning cycle. So there is something seriously wrong. Either you didn't program the ChemID or you have an incorrect sense resistor or something went wrong during relax when the gauge updates DOD for QMax calculations.

Agreed this does not make sense and this big jump in Qmax happened at the same time the SOH and SOC readings started going bad.  

>> It isn't clear to me if Qmax is supposed to be the total capacity of the battery pack or the capacity of the range Full Charge to Terminate Voltage.  Was I supposed to change Qmax when updating parameters for my Terminate Voltage of 3.5 V?

> QMax is a core measurement for the gauging algorithm. You must not update it manually. It must be measured by the gauge. It does this through coulomb count (passed charge) and OCV measurements (during relax) automatically. It's totally unrelated to Terminate Voltage.

Your explanation of the Qmax computation makes perfect sense, but there is one detail I would like to understand.  You say it is unrelated to Terminate Voltage, but SOC as reported by the Gauge is related to terminate voltage, because terminate voltage is by definition 0% SOC.  I assume then in the equation for Qmax, the Gauge is using a separate computation of SOC that is relative to the full voltage range of the battery.  

To use some concrete numbers from my data, on my first discharge after the learning cycle, I discharged from a reported 99% SOC to 0% SOC, with total passed charge of 12796 mAh.  Qmax would then be computed as 12925.  Qmax was updated 3 hrs 43 minutes after the end of the discharge, from 13186 to 13152.  So Qmax moved in the direction of the new computed value.

I then charged it from reported SOC of 1% to 100%, with total passed charged of 12784.  33 minutes after the charge is complete, Qmax updates from 13152 to 13142.  So Qmax is updating in a way that makes sense.

I then change Terminate voltage and Final Voltage from 2500 mV to 3500 mV.  I discharge from 97% to 0%, with a passed charge of 5400 mAh.  Two hours later, Qpass resets to 0, but Qmax does not change (this is the point at which Qmax usually is updated).  From this point forward Qmax never changes from 13142.

If the gauge were to compute Qmax based solely on reported SOC, the new Qmax would be computed as 5400 / 0.97 = 5567 mAh.  Now I know from discharging to 2500 mV that the battery is only really discharged down to about 58% SOC, when you consider the capacity of the entire cell.  So change in SOC is only 42%.  Presumably the gauge knows this two if terminate voltage and final voltage do not affect Qmax.  The gauge would compute new Qmax = 5400 / 0.42 = 12857.  This is consistent with the prior Qmax computations, and I would expect to see Qmax update accordingly.  But Qmax never changes.  

Qmax only changed when I load the golden image onto my target hardware.  It then changes to a value consistent with the total passed charged, but as if the computation did not take into account that 0% SOC as defined by final voltage / terminate voltage is really 58% SOC when you consider the total chemical capacity of the cells. 

> I suggest checking the accuracy of the current measurement (sense resistor, CC gain) and if you programmed the correct ChemID. The first problem you have to fix is the weird QMax update.

I used the Chemistry tab in bqStudio to program the ChemID based on what GPC gave me.  It was working reasonably until I created a golden image and tried to run on my target hardware. I am now back on the dev board, which has never had the golden image loaded to it .  My next step is to load the golden image to the dev board to confirm the golden image works independent of running on my target hardware.

I believe the current measurement is correct but have not been able to verify first hand.  I will make a direct measurement to confirm. 

Thanks,

Dave