Strategy to set each pattern’s brightness to achieve max current draw across all patterns?

Patterns and Code
1

I will be running my projects off a battery source with a max current output.

Measuring the current draw is not an issue and I am happy to do this individually for each pattern.

I want to make sure I understand all the brightness controls I have at my disposal.

The % limit in the Settings tab is a remap of what is sent to the LEDs, correct?

In other words, rgb(r,g,b) is remapped to rgb(r*GB, g*GB, b*GB) where GB is the global brightness setting in the settings tab.

And therefore hsv(h, s, v) is remapped to hsv(h, s, v*GB), correct?

Next item: the UI slider. This is an additional remap. So if that slider is SB, the scaling coefficient is actually (SB*GB), correct?

Next, onto strategy. I want to avoid accidentally sending my PB into a reboot loop if I manually touch the global UI slider and set the brightness too high for the battery for that pattern, so I should arrange my per-pattern brightness so this can be always left at 100%.

To find the right brightness, I would hook the LEDs to a big power supply, set the UI slider to max, and bring up the GB value in the settings tab up until I hit the current limit. This number can then be baked into the pattern inside render(), by scaling the r, g, b and v values for every LED.

In summary, I would then have:

  • UI global brightness slider at 100% always.
  • Settings tab global brightness at 100% always.
  • Each pattern has a brightness scale number as determined above.

Thoughts and comments?

2

I just tweak with max brightness in the settings with a switch between a PB and the light strip so when I send the PB into a reboot loop, I flip the switch and lower the max brightness in the settings by a point or two, repeat.

Yeah, I think that approach wouldn’t be a bad idea. Throw in a top-level var for the brightness once you find them for whatever… Then set brightness back to 100% and use the var in your patterns’ brightness in the render loops.

Hmm… It’s just a shame that the pixelblaze gets stuck into a reboot loop instead of detecting that outgoing amps is getting too high for the amps it’s able to get, and go “Wosh man, this is too much, I draw the line here!”. Damn physics for making this simple-sounding idea into something disgustingly complex and expensive!

1 Like
3

I also have a switch on the LEDs, or when the PB is accessible, a power-only plug to switch to in these situations.

The PB can’t know the amps, but it can detect a reboot loop. Maybe if it notices 3 immediate reboots in a row it could stay black or set the brightness to 50% for 60 seconds.

1 Like
4

The scenario I want to avoid is having to touch the setup at all, so a switch works for development, but not that convenient on my bike setup: I’ve made the (perhaps questionable?) decision to power the strips through XT60 connectors, with the PB receiving power back along the 4-pin weatherproof connector. I’d have to unscrew, and plug in an auxiliary micro-USB to just the PB to gain access again.

Definitely something to think about for a future build—no time to change things up now.

I experimented with the approach I described in my post above and it seems to be working well. The only caveat is that, for some patterns, the brightness setting in the code depends on other parameters in the code. For example, a fire program, if the flames get higher up the strip.

Regarding the reboot loop, I found this documented here:

On the topic of documentation… I’ve found it to be good, but I was surprised that something as important as reboot loop detection was only posted to the forum, and not part of the official docs. Did I miss it elsewhere?