MAX17048 on ESP32 WROOM (Type C) Issues and/or Misunderstanding

Maybe I’m not understanding how I am supposed to use the MAX17048 fuel gage that came on board my ESP32 WROOM Type C boards, but I have yet to see this chip reliably report state of charge. Instead, the SOC curve over time looks more like a battery voltage discharge curve instead of a linear-ish SOC curve.

For instance, during one discharge cycle, the battery dropped from 57% to 7%, a 50% loss, in 51 hours. Then, at the end of the discharge cycle it took 51 hours to go from 10% to 5%, which is a mere 5% compared to 50% mid charge.

I contacted Analog Devices and they told to use another fuel gage or get the batteries I am using characterized by them, which runs about $5k.

What could I be doing wrong or misunderstanding that would cause the MAX17048 to behave this way? Is there another way to get an accurate SOC report without doing the battery characterization Analog Devices recommends?

Check out the datasheet pg 8 (and others) https://cdn.sparkfun.com/assets/b/b/2/c/b/MAX17048.pdf for more details on how the SoC errors are dealt with, etc

You could also likely characterize it DIY mapping the values read vs externally measured and use some variables to linearize the values, whichever floats your boat :slight_smile:

I’m confused. What exactly on page 8 will help me address this issue?

Why map voltage to soc when I have a party on board that should do that?

Oops, pg 7

Because the board knows nothing about the battery until it’s being used over time (batteries come in many flavors!)…it has to ‘learn’ the curve.

I was saying if you don’t like Maxim’s implementation, you could DIY one as an alternative

I don’t see where in the datasheet it says this is a “learning” style fuel gauge. However, I do see on the first page where it mentions that this IC uses their ModelGauge algorithm which eliminates the need for coulomb counting and learning cycles.

What am I missing? Is there some way to put this in learning mode vs ModelGauge mode?

Keep reading past that 1st paragraph, please. Every single aspect is covered on pages 7 & 8.

It really doesn’t matter who is right about that, because here is the real issue: if it is a learning fuel gauge, why isn’t it learning my batteries? How many cycles should it take to learn, maximum, in Sparkfun’s experience?

In case anyone else runs into this issue I have confirmed from Analog Devices support that the MAX17048 is not a learning fuel gauge. I don’t know what TS-Russell is trying to tell me to look at on pages 7 and 8, but if you read over the datasheet carefully (and contact Analog Devices), you will find that the only way to get an accurate SOC readings from the MAX17048 is to have Analog Devices perform a $5k battery characterization.

Sigh… What a disappointment.

I’d suggest that Sparkfun moves to something more like the MAX17055 that has the m5 ModelGauge algorithm that does not require an expensive battery characterization.