nRF Fuel gauge SOC calculation issue

[AntonZ]

Hi!

I'm testing the application with the custom Battery pofile I generated with nPM PowerUP app.
During testing I found the issue with the SOC value calcultation depending on the charger connection state.

In case the MCU (nRF5340) is reset while USB is connected (with active charger), the SOC is calculated as follows (using the nPM1300 sample from the SDK, NCS v2.6.2):

*** Booting nRF Connect SDK v3.5.99-ncs1-3 ***
nRF Fuel Gauge version: 0.9.2
PMIC device ok
V: 4.116, I: -0.163, T: 25.41, SoC: 7.56, TTE: nan, TTF: nan
V: 4.116, I: -0.162, T: 25.41, SoC: 7.57, TTE: nan, TTF: nan
V: 4.121, I: -0.162, T: 25.41, SoC: 7.59, TTE: nan, TTF: nan
V: 4.121, I: -0.162, T: 25.41, SoC: 7.60, TTE: nan, TTF: nan

Yet in case the MCU is reset with USB disconnected, I get correct SOC predictions:

*** Booting nRF Connect SDK v3.5.99-ncs1-3 ***
nRF Fuel Gauge version: 0.9.2
PMIC device ok
V: 4.057, I: 0.007, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.057, I: 0.007, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.057, I: 0.007, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.062, I: 0.007, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.067, I: 0.007, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.140, I: -0.163, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.140, I: -0.163, T: 25.31, SoC: 100.00, TTE: nan, TTF: nan
V: 4.135, I: -0.163, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.145, I: -0.163, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.140, I: -0.163, T: 25.41, SoC: 100.00, TTE: nan, TTF: nan
V: 4.145, I: -0.163, T: 25.41, SoC: 100.00, TTE: nan, TTF: 9963

As you can see, according the the current direction in the log above, I've connected charger after the MCU reset and SOC value remains correct.

This issue leads to the incorrect device behavior during the OTA process, since it requires power supply to be connected (business logic) and perfroms reset to boot new FW.

Is there some bug of the algorithm or should I disable charger to call 

nrf_fuel_gauge_init();

and enable it again after that?

Thanks,
Anton

[Tharaka]

AntonZ said:

Hi

There’s an updated Fuel Gauge library available with the latest NCS releases. I suggest upgrading to that version for the best experience.
https://docs.nordicsemi.com/bundle/ncs-3.0.0-preview2/page/nrfxlib/nrf_fuel_gauge/README.html

Initializing the Fuel Gauge while the battery is already charging and MCU is resetting can lead to inaccuracies, because the battery voltage response may fluctuate under load or the system might briefly reset both can contribute unfavorablely for initialization.

It is best to initialize fuel gauge before enabling the charging process (as you already mentioned) or ideally when battery is at some rest condition. Anyway, its worth noting that the Fuel Gauge is designed to correct initialization errors over time as the battery discharges.

Tharaka

[Tharaka]

Hi Anton

I would like to have look at your battery model file. Can you share it ?  Also if possible the project folder created during the battery profiling process.

Tharaka

[AntonZ]

Hi Tharaka,

Sure, here it is:

Battery.zip

[Tharaka]

Hi Anton

Thanks for sharing the files. I had a quick look on the data.
It appears that the battery resistance is unusually high and there’s a sudden 750 mV jump in voltage while charging just enabled during the battery profiling stage.



Fully charged voltage, just after charge completion,is also 4.04V. 




This is quite range considering the LiPo battery type you are using.This might also explain why the Fuel Gauge is estimating a lower capacity (around 440 mAh instead of a value quite closer to rated 600 mAh).
Battery model estimates much higher internal resistance during profiling process.

This is the reason you are seeing quite strange behaviour in the fuel gauge.

From my experience this can happen due to several reasons,

Incorrect Profiling Setup: If the battery was not properly connected to the Fuel Gauge board or if there were large contact/cable resistances, the measured voltage/current data could be distorted.

Degraded Battery: A worn or damaged battery can exhibit increased internal resistance and abrupt voltage jumps.


Ideal solution would be to repeat the profiling step with a fresh battery with proper connection to the nPM1300-EK + FG board.

But not to keep you waiting for an another 48 hours i have attached you similar Pre-Profiled battery models to match your battery spec for early evaluations.

600mAh_Models.zip


You can initialize the FG even if the OTA process is completed, and charger is ON with these models.

Also since you are using a older version of the FG library, i suggest you to call the Fuel Gauge initialization function nrf_fuel_gauge_init() everytime after a charge completion This ensures that the FG calculations are based on a stable, fully charged state, reducing any discrepancies caused by residual conditions from charging using this generic battery model and much accurate for discharge mode fuel gauge estimations.

You could use the charge completion event (docs.nordicsemi.com/.../charger.html from the NPM1300 BCHGCHARGESTATUS register to trigger the fuel gauge reinitialization (nrf_fuel_gauge_init).

Let me know if this helps. 

Thanks !!

Tharaka

[AntonZ]

Hi Tharaka,

Thanks for the reply and the explanations related to the battery model.
This also explains wrong SOC (with my model it shows 100% at around 4.05V) while LP model you suggested shows 88.7% which I believe is more accurate.

As for the issue with the MCU reset while charger is connected, the reasom is other.
I did some more testing and found out that the first reading I get from the nPM1300 through Zephyr driver gives me voltage and current as if charger was active, so the model is not able to estimate battery level properly.
This might also be a bug in the example for the nPM1300.

As a workaround, at the initialization stage of the Fuel gauge algorithm, I disabled charging functinality and did two readings from the nPM1300 so as to "flush" first voltage/current values from it.
Please check the following log (MCU is reset with charger connected):

[00:00:02.196,228] <inf> app: *****:: nRF Fuel Gauge version: 0.9.2
[00:00:02.197,631] <inf> app: *****:: Charger init (regs: SET: 0x1; CLR: 0x1)
[00:00:02.199,645] <inf> app: *****:: Charger disabled (regs: SET: 0x0; CLR: 0x0)
[00:00:02.704,589] <wrn> app: *****:: (init) NPM1300 data: 4.042000V, -0.471000A, 25.102783°C
[00:00:03.209,533] <wrn> app: *****:: (init) NPM1300 data: 3.857000V, 0.000000A, 25.205627°C
[00:00:03.214,752] <inf> app: *****:: Charger enabled (regs: SET: 0x1; CLR: 0x1)
[00:00:03.219,848] <inf> app: *****:: NPM1300 data: 3.862000V, 0.000000A, 25.205627°C, 52.964569%
[00:00:04.224,975] <inf> app: *****:: NPM1300 data: 3.862000V, -0.046000A, 25.102783°C, 52.964569%
[00:00:05.230,102] <inf> app: *****:: NPM1300 data: 4.047000V, -0.467000A, 25.102783°C, 52.964569%
[00:00:06.235,229] <inf> app: *****:: NPM1300 data: 4.047000V, -0.467000A, 25.102783°C, 52.980389%
[00:00:07.240,356] <inf> app: *****:: NPM1300 data: 4.042000V, -0.467000A, 25.102783°C, 52.995975%

As you can see, first reading from the nPM1300 after disabling charger shows incorrect values.

I guess that it might be related to the Automatic measurements during charging.

So, with such modification I'm now able to get more accurate SOC when restarting MCU with connected charger.

Regards,
Anton

[Tharaka]

Glad that you have found a workaround for MCU reset and everything is working properly now. 
Good luck with your project !!

Regards 

Tharaka