SoC, State of Charge, stuck at low value after cold weather

Firmware
1

For several years on my Electrons (now OS 3.3.1) I’ve been using

FuelGauge fuel;
volts = fuel.getVCell();
SoC = fuel.getSoC();

This winter, after some cold weather (< -10C), the SoC reading has been stuck for over 3 weeks at a very low, but not constant, level (~35%). Because I use SoC to set the sleep time (using SLEEP_MODE_DEEP), my reporting of data is now only a couple times a day. The electron is inaccessible ‘till spring and for now I can live with a low reporting rate, but I’m very curious why SoC stays low, yet getVCell has increased and now reports voltages from 3.85 to 4.01 . I thought SoC was just a calculation based on the volts. So why, for a week now, has volts from getVCell risen to a normal range that I would expect to generate a SoC of ~70 to 90% yet SoC from getSoC stays around 35% .

I know I am abusing the LiPo battery (the one that came with Electron) with the cold but my question is about the calculation of SoC from volts and why volts would increase to around 4.0v but SoC would stay around ~35% ?

thanks, john

2

The MAX17043 is a model fuel gauge, which uses a model of the battery discharge profile, along with voltage information, to derive a SoC. My guess is that the sleep mode you are using is powers off the fuel gauge to safe battery (reasonable), however when the device wakes up, it's not staying awake long enough for the model to recalibrate before turning back off. This is only a guess.

3

Hi John

rickkas7 is right, Since Device OS 1.5.0, the system force-sleeps the MAX17043 during System.sleep(), freezing the ModelGauge algorithm. On wake, you get a stale SoC from however many minutes/hours ago. If your wake window is short (which it is, because you're trying to save battery), the model never catches up. Cold weather compounds it because Device OS doesn't update RCOMP for temperature either.

I've been dealing with this since 2020. I even asked Particle directly to add an option to keep the fuel gauge awake during sleep: Put Electron to sleep but keep fuel gauge awake on 1.5.0 . Never
got a response. Six years later, here's rickkas7 guessing at the same problem.

To add insult to injury, I was forced to upgrade to Device OS 3.3.1 because the cellular modem on my Electron is not supported by older versions.

The "fix": call fuel.quickStart() after every wake. It forces a fresh OCV measurement and resets the model from scratch. Works well if you do it before the modem powers up (low load = VCELL is close to true OCV). I also built a voltage-to-SoC sanity table that detects when the gauge is lying and triggers quickStart() automatically.

The real question remains: why is Device OS sleeping a 50 µA chip to save power while keeping a 10 mA cellular modem in network standby? The math doesn't math. But I'm sure we'll get an answer any year now.

1 Like