Power management in watts/amps/volts?

I’m tinkering with a PB v3 with my shiny new Fibonacci 256 and loving it. But I miss being able to set power consumption maximum (WLED, FastLED). All I find in PB is a brightness limiter in percentage. Am I missing something?

Eg, my board has 256 LEDs, so max current on all white is something like 9+ amps (5v). I don’t plan on actually doing that, as heat is a thing. So I’d rather use a smaller supply. It’d be nice to be able to define my power as 2800ma while using a 3000a supply. But what brightness max to use … trial and error until I see glitching? heh :slight_smile:


Hey @numindast! Welcome to Pixelblaze!

You can generally use the brightness limit as a percentage of your total possible current draw.

To be more conservative, I’m going to use the 15.36 amps max draw listed on Jason’s Fibonacci 256 info page (but I agree with you - I have a F256 with me right now but no ammeter right now; I see they’re 3535 chips, so 9A max may be correct).

So, for your example, since you’d like to draw no more than 2800 ma out of the 15.36 A the F256 could draw, you’d set the Limit Brightness Setting to 2.8 A / 15.36 A = 18%.

Hope this helps - if you have an ammeter, check out what you get with a full white draw (carefully, maybe using the global brightness slider in the top left to ease into it).

This pattern produces full intensity white:

export function render(index) {
  hsv(0, 0, 1)
1 Like

Thanks Jeff! Makes perfect sense. My biggest power supply at the moment is 30w so I haven’t a means to try it out, and I doubt my multimeter’s fuse would survive an attempt.

This disc sure puts out a lot of light, even with just 3A to play with right now. Wow!

1 Like

i do think @numindast has a good point though…

ive been building a number of carryable LED items. they’re powered off 18650 cells. also via the mode button, the user/owner fo the item can change the pattern to whatever they like at the moment.

picking a uniform brightness isn’t helpful here because some patterns drain a whole lot more power than others, since the total power consumption has to do more with the color and how many LEDs are active

having a upper limit on estimated watts or amps would be really great here… if a high power pattern is selected, the brightness could be scaled down, but if a lower power pattern is used, then it could run at closer to full brightness.

this would also be quite beneficial to designing the wiring, power converters, heat dissipation, etc if we know we wont exceed some threshold. it would also make estimating total runtime much easier.

count me in along those who’d be very happy to see a way to set a max power rate as an alternative to just a brightness scale.

1 Like

As a hack … maybe adjust the current brightness based on the previous frame’s total amperage?
Off the top of my head, as follows. Just use rgb_autobright() instead of rgb().

Other ideas include …

  • smoothing Adjust over time
  • non-linear calculations of amps … or at they reasonably linear?
Code which is totally untested
// Variables for you to set:
// Ramp, Gamp, and Bamp are amps-per-full-bright-LED by colour.
// maxAmps is the total number of amps available.

Adjust = 0.1 // start dim so we don't blow a fuse with a bright first frame

// Amp accumulators
Rtotal = 0
Gtotal = 0
Btotal = 0

rgb_autobright(r,g,b) {
  Rtotal += r
  Gtotal += g
  Btotal += b

beforeRender() {
  usedAmps = Rtotal * Ramp + Gtotal * Gamp + Btotal * Bamp
  if (usedAmps > maxAmps) {
    Adjust = maxAmps / usedAmps
  } else {
    Adjust = 1
  Rtotal = 0
  Gtotal = 0
  Btotal = 0
1 Like

I love this, @sorceror, because it accounts for the main reason Pixelblaze doesn’t have this feature already (as hinted in some prior thread): The output isn’t buffered, so there’s no moment at the end of a frame where you can look back at all calculated pixels, and say, “OK, great, now let’s compute the total brightness and re-scale all pixels before sending out”.

For smoothing Adjust over time, maybe the exponential-weighted moving average is good: Take 10% of the most recent frame’s total brightness and add it to 90% of the prior running average.

In my experience the amps have been reasonably linear.

Id be curious about the GS8206, or any LED with built-in gamma correction. I would think that would add a bit of complication to the current calculation.

There’s also quite a range of different max currents, and the formula differs a bit for the series element LEDs like WS2815 / GS8206. There’s 10 and 5 mA/element versions of WS2812s. RGBW is another beast, and the white element tends to draw a bit more than the others, and there’s different methods for converting RGB to RGBW.

I haven’t seen a good clean dataset, though there are some decent approximations like quinled tables.

I think to be super accurate the power calculation would have to be after any/all color math, very near the driver level, and with detailed knowledge of the LED type/subtype specifics.

Not that it’s impossible, just a fair bit of work. When I implement it I do want to try to get it pretty accurate over a one size fits all approach.

1 Like

For what it’s worth, a while back I measured the current drawn by around 40 different patterns on a (non-Pixelblaze, FastLED+Teensy) project of mine using a clamp meter. The clamp meter is a really useful bit of kit, it can show the instantaneous current passing through a wire, or instead track the max or min current it sees.

I discovered that the maximum current draw for each pattern ranged from ~1.6A to over 10A, depending on which pattern was being displayed. The current fluctuation for a single pattern could be quite large too, sometimes a difference of 3x or more from min to max in the worst cases (but generally 1.5x-2x if I recall correctly). Sound reactive patterns in particular were troublesome, often getting excessively bright during sudden increases in volume.

Before measuring I had my suspicions about which patterns would be the worst offenders but I was still quite surprised by some of the results, so it was a very useful process to go through. Once I had the data it was fairly straightforward to take the worst 10 or so patterns and tweak them to use less power - usually to about 1/2 to 2/3 what they had been using, with little obvious visual difference in the end result.

I’ve been meaning to do something similar on a Pixelblaze project of mine since exactly the same process would apply, but the power supply there is a couple of USB powerbanks and they just cut out if the current gets too high anyway, so it’s pretty obvious if a pattern is drawing too much power!

@wizard - i believe it that it could be challenging to accurately calculate the total power usage given all the variables you mention.

maybe it could be abstracted somewhat, such as assigning a score to colors in use, the fill, and brightnesses and whatever known quantities are at the PB controller level without getting into the nuances of the LEDs, chipsets, etc - that would provide enough data for the builder who could measure the actual power draw and work out an rough correlation between the score and the power draw and PB configuration could allow for setting a limit on the power score?

Maybe the PB could have an integrated ammeter and a deep learning system to predict power requirements!



And… just for fun, I’ve implemented real-time power analysis for the next version of Pixel Teleporter. (No deep learning system yet though!)

@Wizard’s right. It’s a can of worms, and there’s not a lot of solid data out there for the many, many, many LED variants available.

To simplify, I built 3 basic models – RGB, RGBW and constant current (like the GS8206). There are pre-built profiles for the some super common LED models, and the ability to enter custom data for other types.

Since it’s modeling and not measuring, it’s never gonna be perfect. (And I’ve deliberately leaned towards estimating a bit high, to avoid anyone setting things on fire.) But you can use it to get ballpark figures on how much power a pattern burns in a specific configuration, and choose power supply/batteries accordingly.