Sometime fuel.getSoC() return zero

Troubleshooting
1

Sometime calling fuel.getSoC() return zero, but the battery is not drain.

I have this in the code:

before everything
FuelGauge fuel;
float currentSoc = 0;

in setup
fuel.quickStart();

when I publish (once every 15 minutes, in between System.sleep(SLEEP_MODE_DEEP, _seconds, SLEEP_NETWORK_STANDBY):wink:
currentSoc = fuel.getSoC();

Capture

what can cause this wrong reading?

2

Capture

I’ve a solar panel connected to the Electron, could it be the cause?

3

It looks like you are missing Publish Events from the Electron during the times of “Zero” readings also.
Actually, it appears the Electron is sending the Publish more than 15 minute intervals (=4 per hour).

Your CODE doesn’t appear to function as you intended, and that’s likely related to the “Zero” readings.

4

Sorry I wasn’t clear, these are just few instruction of my code not the full source code.

I have an event that publish every 15 minutes sensor readings and the SoC value, then I have a webhook that send the value to ThingSpeak.

There is no issue on publish, system works in SEMI-AUTOMATIC mode and I have all in place to stay connected to the cloud (keepalive & so on).

All works very well, except sometime I got this zero reading…

PS. the code send a publish every hour during night or during day when SoC is < 15 otherwise every 5 minutes, in my first post I wrote 15 minutes, but it’s not the real scenario.

5

Today again same issue, always around midday, when the solar panel get most of solar radiation. Is just a coincidence?

6

Is there are reason you’re using fuel.quickStart()? In SLEEP_MODE_DEEP the fuel gauge is still powered and continually recalibrating on every startup it will produce less accurate readings. It might also produce 0 if the recalibration hasn’t completed by the time you call getSoC().

IC Power-Up

When the battery is first inserted into the system, there is no previous knowledge about the battery’s SOC. The IC assumes that the battery has been in a relaxed state for the previous 30min. The first A/D voltage measurement is translated into a best “first guess” for the SOC. Initial error caused by the battery not being in a relaxed state fades over time, regardless of cell loading following this initial conversion. Because the SOC determination is conver- gent rather than divergent (as in a coulomb counter), this initial error does not have a longlasting impact.

Quick-Start

A quick-start allows the MAX17043/MAX17044 to restart fuel-gauge calculations in the same manner as initial pow- er-up of the IC. For example, if an application’s power-up sequence is exceedingly noisy such that excess error is introduced into the IC’s “first guess” of SOC, the host can issue a quick-start to reduce the error. A quick-start is initiated by a rising edge on the QSTRT pin, or through software by writing 4000h to the MODE register.

1 Like
7

Good point, I added it trying to avoid the problem. Let’s remove it and see what happens.
I’ve also make a workaround into the code to bypass when is 0 because when SoC is under 15 I go sleep one hour instead 15 minutes.

8

My electron is connected to a 2700mAh LiPo cell and it will read 0% for half a day before the battery actually dies FYI.

9

To me are wrong readings caused by something unknown.