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

**URL:** <https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291>\
**Category:** ESP32\
**Created:** [April 16, 2024, 12:56am UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291 "2024-04-16T00:56:49Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![ZenEE](https://avatars.discourse-cdn.com/v4/letter/z/cab0a1/32.png) [@ZenEE](https://community.sparkfun.com/u/ZenEE)\
**Post date:** [April 16, 2024, 12:56am UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/1 "2024-04-16T00:56:49Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![TS-Russell](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/ts-russell/32/6092_2.png) [@TS-Russell](https://community.sparkfun.com/u/TS-Russell)\
**Post date:** [April 16, 2024, 10:08pm UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/2 "2024-04-16T22:08:27Z")

</div>

Check out the datasheet pg 8 (and others) [https://cdn.sparkfun.com/assets/b/b/2/c/b/MAX17048.pdf](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 🙂

---

<div class="post-metadata">

**Author:** ![ZenEE](https://avatars.discourse-cdn.com/v4/letter/z/cab0a1/32.png) [@ZenEE](https://community.sparkfun.com/u/ZenEE)\
**Post date:** [April 17, 2024, 2:26am UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/3 "2024-04-17T02:26:19Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![TS-Russell](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/ts-russell/32/6092_2.png) [@TS-Russell](https://community.sparkfun.com/u/TS-Russell)\
**Post date:** [April 17, 2024, 6:33pm UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/4 "2024-04-17T18:33:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ZenEE](https://avatars.discourse-cdn.com/v4/letter/z/cab0a1/32.png) [@ZenEE](https://community.sparkfun.com/u/ZenEE)\
**Post date:** [April 18, 2024, 1:41am UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/5 "2024-04-18T01:41:17Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![TS-Russell](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/ts-russell/32/6092_2.png) [@TS-Russell](https://community.sparkfun.com/u/TS-Russell)\
**Post date:** [April 18, 2024, 3:02pm UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/6 "2024-04-18T15:02:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ZenEE](https://avatars.discourse-cdn.com/v4/letter/z/cab0a1/32.png) [@ZenEE](https://community.sparkfun.com/u/ZenEE)\
**Post date:** [April 18, 2024, 9:19pm UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/7 "2024-04-18T21:19:04Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![ZenEE](https://avatars.discourse-cdn.com/v4/letter/z/cab0a1/32.png) [@ZenEE](https://community.sparkfun.com/u/ZenEE)\
**Post date:** [April 19, 2024, 11:31pm UTC](https://community.sparkfun.com/t/max17048-on-esp32-wroom-type-c-issues-and-or-misunderstanding/47291/8 "2024-04-19T23:31:37Z")

</div>

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.
