BQ27441-G1: Golden image/learning function/ram values

The built in ChemID is not a good match (DOD error is 7.08%). However, this doesn't necessarily lead to a 20% SOC jump. This likely has a different cause.

When you reset the gauge (e.g. power cycle), it loses all data that it learned and it must be reconfigured (this is indicated by the ITPOR bit). After configuration, you have to issue a SOFT_RESET command after which the gauge takes a voltage, current and temperature measurement and then estimates remaining capacity (RM) with a discharge simulation from this reference point (determined by this measurement) to terminate voltage, full charge capacity (FCC) with a discharge simulation from the configured charge termination (V at Chg Term, Taper Rate) to terminate voltage and SOC = 100*RM/FCC.

The DOD error will affect  RM (and hence SOC calculation) but depending on the actual DOD of the cell this is likely not anywhere close to 7%. What's more likely is that your configuration doesn't match what the gauge used before the reset. This may be the 100% SOC point defined by V at Chg Term (check that this is accurate in your configuration) because the gauge will learn (measure) this when it detects a charge termination. It may be the load prediction (avg I/P last run - the gauge also learns this and you should set this to a reasonable value in your configuration). It may be the impedance profile (again learned) or even QMax (also learned).

The 20% error could also be due to excessive current at SOFT_RESET. The gauge cannot accurately determine DOD0 (the reference point) if the cell isn't relaxed. By definition, if there's a load current (worse if that is relatively high (>C/10)), the cell won't be relaxed so the gauge has to compensate with the estimated impedance for the estimated reference point and all that has an unavoidable error. That's why it's generally a terrible (!!!) idea to reset or configure the gauge if ITPOR isn't 1. The gauge's algorithm should not be interrupted unless absolutely necessary.

If you have to power cycle/reset the gauge, you can mitigate the subsequent error (except the error due to the poor OCV reference point - that can't be fixed with configuration but is a system problem) by saving the following information periodically (e.g. once a week) and restoring it after a reset (together with your other gauge configuration like current thresholds etc.)

* subclass state (this will preserve learned info like QMax or load prediction or charge termination)

* subclass Ra (this is the impedance table)

Hi Dominik,

Thank you for the quick response.

To expand on what Mike has already said, we noticed that on resetting our device, the initial SOC would change depending on if we are charging/discharging the battery. For example:

• say the actual SOC is at 30%
• if I reset with no USB connected the initial SOC starts at ~30% as expected
• with USB connected it starts at ~50%

I believe this is caused by "excessive current at SOFT_RESET" as you said, except I believe the SOC calculation is off due to charging instead of load on the battery.

We are using the bq24160 Li-Ion charger. To avoid a higher OCV and current on FG initialization I tried the following:

• Disable charging during FG initialization (using charge-enable CE bit of bq24160)
• Wait ~1 second for OCV/current to settle
• Configure FG with appropriate design capacity, etc
• Trigger SOFT_RESET
• Wait for OCVTAKEN in Flags to be set
• Re-enable charging

This seemed to work momentarily (the SOC reported is ~30%), but about a second later the FG seems to update again, causing it to jump to 50%.

I also tried using EXIT_CFGUPDATE instead of SOFT_RESET, which works until we put the FG into SHUTDOWN, in which case the OCV is taken again and SOC reports as 50%. 

As you said this all seems like a system issue, rather than an issue caused by the ~7% DOD error (which I think we're ok with short-term).

Do you have a recommended way to handle FG initialization when charging is enabled? Is there a way we can compensate for this, or a variation of what I've already tried that you think will work?

Thank You,
Josh

Also is this something that would be improved by putting the battery through several charge/discharge cycles?  If we do this on 10 devices, could we pull some data out of the ram that could be used to pre-condition the circuit at the factory?

I ran some more experiments and seem to have gotten it to work (reported SOC with USB charger inserted/removed are the same, bold is what I changed from my previous post):

• Disable charging during FG initialization (using charge-enable CE bit of bq24160)
• Wait ~1 second for OCV/current to settle
• Configure FG with appropriate design capacity, etc
• Trigger SOFT_RESET
• Wait for INITCOMP in CONTROL_STATUS to be set (takes ~5 seconds)
• Re-enable charging

Does this sound like a reasonable solution to you, or is there a better way that you'd recommend.

I think this, along with only re-configuring the FG if ITPOR is set could work. The only time it should take 5 seconds to initialize would be from POR/exit shutdown.

Thank You,
Josh