Canonical LED Power Consumption

It's been observed on multiple occasions that the actual measured power consumption from various strip- and strand-type LEDs (such as the LPD8806 and WS2801 "pixels") doesn't match the figures given in the datasheet -- it usually turns out to be a bit less. This is true. There are a few reasons for that, which I'll try to explain:

The first factor is simply "fudge" in the datasheet numbers. This isn't really meant to deceive, but is more about giving conservative, worst-case values so that nobody can rightfully complain that their lighting is drawing more power than the manufacturer promised. Let's call it the cover-your-butt factor. There's a certain amount of manufacturing variance in every component (e.g. 5% resistors), and rounding up to a figure like 60 mA for a pixel makes sure that every case is represented...it's also simpler in print and for doing mental estimations for many-pixeled installations.

Second is the resistance of the wire joining the LEDs. The longer the wire, the greater the resistance...which, by Ohm's law, is inversely proportional to current. If you apply power to a single end of a long run of LEDs, those toward the opposite end get progressively dimmer as they're starved of current. If you measure 1 and 2 meter lengths powered in this manner, you'll see that the numbers don't add up -- the 2 meter strand is using less than 2x the current, because of this resistance. This is why I always strongly recommend power taps every meter for the strip-type LEDs, and every 25 pixels for the strand type.

Third, the datasheet numbers represent the maximum case -- for an RGB LED, that's white at 100% full intensity. But on average you'll probably be running them much less than this. For a game of "snake" on an LED matrix, you might have fewer than 10% of the pixels actually lit...or if displaying animation, like the rainbow swirl from the LED belt kit, most of the LEDs are at an intermediate brightness level, they're not all going full blast all the time. The relationship is pretty much linear, or close enough...an LED PWMing at a 50% duty cycle will use about 50% the power of a fully-lit one.

Finally, a phenomenon I can only describe as "mojo," wherein the power draw of a color pixel is slightly less than the expected sum of the components (even after factoring out the power use of the driver chip). For example, measuring current for 100% red and 100% blue, then for 100% red+blue (magenta)...the latter comes out slightly less. Why? I couldn't tell you, but it's there. This is more pronounced when a strand is inadequately powered.

Measured figures:

Code: Select all | TOGGLE FULL SIZE
`WS2801 PixelsA = 50 pixels, powered from one end (average taken from 2 separate strands)B = 50 pixels, powered from both ends (2 strand average again)Configuration              A     B-----------------------  ----  ----Off (driver chips only)    33    33 mA @ 5VDC100% R                    947   948100% G                    943   944100% B                    944   946R + G                    1804  1861G + B                    1788  1858R + B                    1820  1863R+G+B                    2342  2778`

A couple of observations: notice the higher consumption on strand "B," the one powered from both ends. This is a good thing, it means more pixels are running at their intended full color. Note also that the "mojo" problem goes away when the strand is fully powered (B). Moral of the story? 25 pixels to a power tap...it's not just a good idea, it's...well, okay, it is just a good idea!

From the above, we can estimate a better average current use for each WS2801 pixel at 0.66 mA (driver chip) + 18.3 mA per color component (R, G, B) * duty cycle (0-100%). For a properly-powered white pixel at full brightness, that's 55.6 mA, or about 1.4 Amps for a fully-lit 25-pixel strand.

And here are some figures for LPD8806 strips:

Code: Select all | TOGGLE FULL SIZE
`LPD8806 PixelsA = 32 pixels (1 meter), powered from one endB = 32 pixels (1 meter), powered from both endsC = 160 pixels (5 meters), powered from one end (don't do this)D = 160 pixels (5 meters), powered from both ends (don't do this either)Configuration              A     B     C     D-----------------------  ----  ----  ----  ----Off (driver chips only)     4     4    19    19 mA @ 5VDC100% R                    572   583  1700  2038100% G                    563   575  1649  1993100% B                    562   573  1645  1988R + G                    1031  1062  2340  3021G + B                    1022  1052  2284  2976R + B                    1026  1056  2330  3020R+G+B                    1412  1470  2701  3037`

Notes: the 5 meter cases are shown here mostly to illustrate that even powering both ends of a long strand is not adequate...you really, really want a power tap per meter, period...but I didn't want to cut into my pristine 5m strand until it's being installed, so regard the rightmost columns above as a lesson in What Not To Do (it should be drawing about 7 amps for proper color & brightness, but is so starved of power that we measured less than half that). Using the more reasonable "A" column figures (1m max to power), we can estimate current use per LPD8806-based pixel at 0.125 mA (driver chip) + 14.67 mA per color component (R, G, B) times duty cycle (0 to 100%). For a properly-powered white pixel at full brightness, that's 44.1 mA...so figure about 1.4 Amps per meter, fully-lit.

That's a lot of annoying math, especially when you get into colors and animation. We have a big WS2801 LED tutorial/kit in the pipeline, and this includes a Processing library which, among other things, can do these calculations automatically...pass it an RGB image, and poof, it gives back the estimated current required for the whole thing...also charge (mAh) over time for animation. Neat stuff. Keep your eyes peeled!

pburgess

Posts: 4104
Joined: Sun Oct 26, 2008 2:29 am

Re: Canonical LED Power Consumption

Thanks for the analysis Paul. :D This is a common question with no simple answer.

Posts: 84034
Joined: Sat Feb 07, 2009 10:11 am

Re: Canonical LED Power Consumption

Thanks for this - exactly what im investigating..

would you mind commenting on my points below..

i have currently

2 meters of lpd8806 ( as a test with plans to by quite a bit more if all works)

12v / 5a mains power supply ( sold by adafruit)

Naturally i need to lower the voltage down to 5v, so have ordered a few a LM2575T step-down switching regulators ( + heastsinks just in case things get hot) which should do, but these are limited to 1 amp current. Have to figure how to connect these , but im sure i'll ork it out. If there is a better solution to this i'd love to know.

So, i'll need to power tap as you describe, and to keep within the 1amp limit per led section, gives me max 20 leds approx at full power draw.

Does this make sense technically ?

ALso realise i'll have to cut each segment to power it, but do i need to cut the grnd also, or can this be shared back to the common ground at the arduinio?

Thanks in advance for you assistance..

joe
josepi90

Posts: 7
Joined: Fri Nov 11, 2011 1:20 pm

Re: Canonical LED Power Consumption

My conclusion is that strips which work at 12 volts lose less and are better than the ones which at 5 volts because we do not have to power them in as many places as in those at 5 volts, am I right?
nahiko

Posts: 24
Joined: Thu Nov 03, 2011 7:42 am

Re: Canonical LED Power Consumption

Yeah, it would seem that 24v would be optimal for long runs of LED strung together in series. I am still wondering about whether ground taps are necessary as well... I would think they are, right?

Phil, going back to you post from Oct '08, did you ever do that processing/LDP tutorial? I havent seen it yet, but i may just looking in the wrong place. Thanks for the great info so far

jasonk

Posts: 26
Joined: Thu Feb 10, 2011 4:35 pm

Re: Canonical LED Power Consumption

Hi Jason,

No, never did write that follow up. It's still on my to-do list, but there are still some other things taking precedence. (And then I just applied for Maker Faire, which isn't gonna help with my free time!)

If you're comfortable around lower-level C and Java code, I do have some stuff which builds into a Processing library for another type of LEDs. My plan was to adapt that to the LPD8806. Just haven't yet. But I could point you toward it if you're feeling industrious.

Bitbang mode has lost some of its luster for me because I just know this is gonna be tech support hell. Especially Mac and Linux, with the driver shenanigans that need to be done, and getting stuff to compile on different architectures, and 32- and 64-bit-ness and all that. Paul of PJRC & Teensyduino fame is talking about an optimized Serial.readBytes() function for the 32u4 that I'm hoping might narrow the gap between serial and bitbang I/O rates. If that goes well...even if it's not 100% up to speed with bitbang...the time would be much better spent pursuing that route, because it'll be about a billion times easier for users to deal with.

pburgess

Posts: 4104
Joined: Sun Oct 26, 2008 2:29 am

Re: Canonical LED Power Consumption

Thanks for writing me back so quickly. Unfortunately I am more of a processing/arduino guy than a java/low level c man. I've been working with the ws2801 pixels and programming them in arduino. i'm hoping to get them to play video or come up with some sort of framework through processing to act as a GUI, rather than just punching numbers in the arduino code. any suggestions for something like this that has already been built? any experience with pixelinvaders? I have been looking at their stuff as well which seems to be based around PD as a front end. Maybe that would be more my speed.

Best,

Jason

jasonk

Posts: 26
Joined: Thu Feb 10, 2011 4:35 pm

Re: Canonical LED Power Consumption

Ah! Okay.

I'd suggest, in that case, sticking with the "LEDstream" code on the Arduino, and using either the WS2801 library for Processing (which is in the Adavision git repository) or look at the Adalight and Colorswirl source (in the Adalight repository) to see how the serial data is packaged. (I'd really recommend the library though...aside from having a few nice "cake" features, if I ever do get that bitbang stuff written the syntax is going to be very similar to this lib, regardless of whether theres an Arduino or FTDI chip involved.)