Fuel Gauge LED bias resistor calculation

Have you figured this one out? I'm also interested in the MAX17263 but have the exact same questions you have, having looked at your other posts.

Hiyo;

I can't seem to get any responses from ADI when asking these questions to them directly, so my current state is based on a lot of banging around and trying things (and I'm still learning, so not totally confident). 

But, some notes I've made for myself as I've gone along:

The worst-case scenario for our LEDs is when our battery charge is very low (let's say 3.0V or so). In this state, we have less voltage headroom to push our LEDs with, and we can assume the PWM that the gauge is using to regulate brightness is nearing 100%. The datasheet seems to imply a target current usage of around 5mA. We can write all this as:

R = (Vdd - Vfwd_led) / I

The table in the datasheet shows resistor values for LED forward voltages of 1.8 and 2.8:

R = (3.0 - 2.8) / 0.005 = 40Ω
R = (3.0 - 1.8) / 0.005 = 240Ω

These values are close to those shown in the table and help implicitly suggest context for how Analog Devices is doing their calculations. 

Looking around on Digikey, I found various colors of small (0603 footprint) LEDs with a listed Vfwd of 2.0V each; there are green, yellow, orange, and red ones. This seem like a great spectrum for an LED bar, and using 2V variants of each imply we can use a single bias resistor value across the matrix, rather than needing to muck around with separate resistors for each.

Doing our above math for a 2V LED, we see:

R = (3.0 - 2) / 0.005 = 200Ω

This - I think - means that if we keep our resistor below 200Ω, our fuel gauge should be able to power our LEDs while still accurately measuring Rsense.

I moved ahead with the above assumptions to design and assemble a board that uses 12 various-colored (but same-Vfwd) LEDs and200Ω resistors. When I connect a battery to this board, I see some odd flickering at first (I ask about this in a different post you allude to). I think this is the MAX17263 trying to auto-count the lights. It seems to come up with something different each time, and doesn't seem to "just work" out of the box. 

I've since learned that this device sort of starts up in a hibernation mode, and needs to be configured properly (via I2C) before it can do anything meaningful, including dealing with the LEDs. This includes configuring things like the "empty" voltage, termination charge, and some other things that help it understand what "full" and "empty" mean in the context of my/your design. I've learned that I have to get these right before I can think about the LED behavior (if I screw up the calculations for these settings, the LEDs don't really report things accurately...so, like, half of them will be lit when I know the battery is full, for example). All of this is to say: I've learned to put focus on the configuration of the device itself before messing with configuring the LEDs. 

I think I'm close to getting it working, I'm still chasing bugs in my system here, so take all this with a giant handful of salt! I feel fairly confident that the hardware design notes above are pretty close to accurate though...or, at least, I have a design here where the lights definitely light up with reasonably equal brightnesses using different-color LEDs, so I think I'm on the right track. 

Thanks for the reply! Makes me more confident to start a design with that chip. A bit of a shame that it needs so much configuration when it is advertised as a plug and play device though. Interested to know if you get it working!

For configuration I've found both rust and arduino drivers, could be useful to get it to work granted tou have an I2C interface available.

Cheers!

Thanks for the reply! Makes me more confident to start a design with that chip. A bit of a shame that it needs so much configuration when it is advertised as a plug and play device though. Interested to know if you get it working!

For configuration I've found both rust and arduino drivers, could be useful to get it to work granted tou have an I2C interface available.

Cheers!