Add support for (non linear?) current limited LEDs in auto brightness limiter

[Szabolcs2008]

Is your feature request related to a problem? Please describe.
I have ordered some 12V WS281x compatible LEDs from AliExpress (this), built a simple controller for them (2 channels with 600 LEDs). I realized that I had miscalculated the total current, so I had to current limit it in software. However, it kept tripping the psu's short circuit protection. After testing again with my lab bench psu, I figured out that WLED's current measurement was way off. The limit was set to 8 amps total (this is the rated current of my power supply), but the actual current draw was 10+ amps without getting brightness limited.
After some measuring around, I figured out that these LEDs were a little weird: The current is linear initially, but then it gets clamped at ~10 mA per led, regardless of the color after that point. I did a test again, but now actually recorded the data (I attached the file). It seems like these LEDs have a shared current limit across the colors channels. The limit is only applied when multiple channels are lit simultaneously within the PWM cycle. I could prove this by looking at the current draw with an oscilloscope, and seeing 1 to 3 distinct spikes.

Describe the solution you'd like
I would appreciate if more accurate current calculation for non linear current-limited LEDs got implemented. Ideally, this could be a new LED type, or maybe a toggle for current LED types (eg. WS281x, maybe a second custom type for WS281x). Different LED ICs probably have different thresholds, so the implementation should ideally be generic and parameterizable

Describe alternatives you've considered
My temporary solution was to greatly limit brightness

Additional context
I then wrote a test that goes through some colors and logs the LED current. Based on these measurements, I created a current profile model that matches the measured current with less than 1% prediction error. I used Claude to help prototype the algorithm in Python and produce a C implementation. I also made a proof of concept fork implementing this current model. I have been running it 24/7 on my own LED installation for ~2 months without having any issues, although it has only ever been tested on my exact hardware.

Current profile of one led (this is what I gave to Claude): 1led.txt
I uploaded all of the code I or Claude wrote to this repository
Current prediction code by Claude: predict.py
Proof-of-concept implementation is in this commit.

Thank you for your ideas for making WLED better!

[softhack007]

@Szabolcs2008 if you only want to protect your PSU, maybe you could try an easier approach:

• enter 10mA / LED as custom value
  
  Alternatively, use 30mA/LED which is also a safe value - unless your LEDs have "overcurrent" spikes in the median values.
• Measure the real current draw during the "solid" effects, and compare to the current estimate by WLED. If the estimate is too low, increase mA/LED.
• Set the "Maximum PSU Current" to 80% of your PSU rating, to have some over-current margin

[softhack007]

Update - it looks like WLED has an alternate "wacky old power model", that seems more appropriate for this LED type.
It was initially designed for WS2815 only,

WLED/wled00/bus_manager.cpp

Lines 289 to 290 in 14709dd

	} else { // wacky WS2815 power model, ignore white channel, use max of RGB (issue #549)
	_colorSum += ((r > g) ? ((r > b) ? r : b) : ((g > b) ? g : b));

WLED/wled00/bus_manager.cpp

Lines 198 to 201 in 14709dd

	if (_milliAmpsPerLed == 255) {
	// use wacky WS2815 power model, see WLED issue #549
	_colorSum *= 3; // sum is sum of max value for each color, need to multiply by three to account for clrUnitsPerChannel being 3*255
	actualMilliampsPerLed = 12; // from testing an actual strip

a comment in #549 explains

http://www.thesmarthomehookup.com/the-complete-guide-to-selecting-individually-addressable-led-strips/

You can see the really odd behavior of the WS2815 when it comes to current draw. Basically, a single pixel draws the exact same amount of current at 50% red as it does at 50% white, even though the white consists of red, green, and blue. An awesome commenter in another one of my videos explained why, but the cliffsnotes is that each channel is powered in series instead of parallel, and if only a single channel is wanted the other two are shorted out by a transistor resistor combo to keep the current constant.

[Szabolcs2008]

The LEDs don't have overcurrent spikes, but for example red on 100% brightness can draw the full 1200x10mA alone, without WLED having an idea of this. I had to put the LED current very high, or the limit very low for it not to overshoot the 8.5A max of my power supply, making me have very low brightness.

[Szabolcs2008]

Update - it looks like WLED has an alternate "wacky old power model", that seems more appropriate for this LED type.
It was initially designed for WS2815 only,

I'll test this rq. If it is close enough it might be the solution. Though still, it could probably have some configurability in the UI

[softhack007]

agreed, the idea would be to make this available as an "alternate power model" in LEDs settings, maybe also allow for some kind of "gamma parameter" as an expert setting. For performance reasons, anything that is more complicated that a 256 entries LUT (look-up-table) would be overkill - including any approximation curve (spline, quadratic, or whatever) that needs to be evaluated for each pixel in each frame.

[Szabolcs2008]

update - I tested a clean WLED install with WS2815 LED type, and it looks like it works well this way. (~6A current draw out of 8A limit set)

anything that is more complicated that a 256 entries LUT (look-up-table) would be overkill

agreed, after a second look at the code, the implementation Claude gave me is way too complicated for use on a microcontroller, especially slower ESPs

[Szabolcs2008]

I tested a clean WLED install with WS2815 LED type, and it looks like it works well this way. (~6A current draw out of 8A limit set)

never mind, I forgot to test with pink. blue + red overshoots by a lot, but blue + green, red + green doesnt

[softhack007]

I've looked at your measurements, and indeed it seems that your LEDs have a limit on the current that all 3 colors can draw. I did not plot the values, but they don't look very non-linear to me.

While the WS2815 "wacky old model" is based on max(r, g, b), your leds seems to be based on min(r+g+b, 260) (clamping). This makes prediction possible, but software based current limiting might still fail.

WLEDs current limiter works by temporarily reducing a frame's brightness. If the predicted current is 10% over the max limit, we simply reduce overall brightness by 10%. This work in the two models r+g+b and max(r,g,b).

In some cases, it will not work with your "clamped" LEDs: assume solid RGB(192, 128, 96) => current clamped at max ampere per led. 10% reduction in brightness => RGB(173, 115, 86) still clamped at max. This means the limiter wanted to reduce currents by 10%, but it achieved nothing.

So for colors with several RGB components where the per-LED sum is well above the clamping limit, WLED cannot reliably control currents for your LEDs. We can improve the prediction, for example by adding an option for min(r+g+b, 260) to the WS2815 power model, but there are still scenarios where the limiter will not help. You'll still see overshoots, unless you add strong safety margins in LEDs settings.

If you want to validate my idea, change this line

WLED/wled00/bus_manager.cpp

Lines 289 to 290 in 14709dd

	} else { // wacky WS2815 power model, ignore white channel, use max of RGB (issue #549)
	_colorSum += ((r > g) ? ((r > b) ? r : b) : ((g > b) ? g : b));

into _colorSum += min(260U, r + g + b );

It should improve the current estimation in wled.

[softhack007]

@Szabolcs2008 I've played with your measurements a bit - good old engineer work (analyze measurements in excel), no dumb AI involved.

results are:

• your individual LEDs respond linearly to brightness. No need for "non-linear" treatment of individual colors
• "standby current" is 0.5 mA, not 1mA (WLED assumes 1mA)
• the real max mA/LED would be 10mA, but
  • the "default" model would need 30mA/LED to prevent underestimations in the median ranges (~127)
  • the WS2815 "wacky old model" would also need 30mA/LED to prevent underestimations - but would result in higher max brightness
  • we could add a new "clamped" model that produces better estimates for your LEDs => no under-estimations, but up to 30% over-estimation possible. This would allow for even better brightness. For your LEDs, the best parameters are: standby current 0.5A, 10mA/LED, clamp at 269.
• BUT the "clamped" model is not safe for auto-limiting brightness. There are corner cases where reducing brightness will not lead to reduced currents.

• For 1200 LEDs and 8A PSU, the "always safe" value is around 20mA/LED (just an educated guess), because low brightness underestimates don't matter.

I've attached my analysis sheet in XLS - it a bit cluttered, but maybe you want to experiment with the graphs and parameters.

1led_analysis.xlsx

@DedeHai what's your idea about the topic? I see some options:

• de-couple the "WS2815" model from its built-in 12mA/LED assumption (separate drop-down for "power model"?), and make standby current user-configurable, too. Would result in better brightness & "safe" ABL behaviour for this user.
• add a new "clamped" power model (see my bullets above). Even better brightness, but "unsafe" ABL behaviour, due to clamping (mathematically, min(x, y, z, Const) is not a valid metric. In contrast x+y+z (taxi cab) and max(x,y,z) are valid metrics).
• keep as-is, change nothing

cheers, Frank.

Edit: AI tools are definitely very bad when it comes to math and numbers. Some AI's struggle when counting to four ;-). Your measurements - and what the AI made out of it - are a good example of AI being "not exactly right" :-).

[DedeHai]

there is no way the ABL can be implemented for this as it is not possible to derive a brightness factor from the (clamped) color sum. It probably requires a binary search which is just not feasible. The other approach would be to run some approximated statistics by counting the total brightness (r+g+b) and put them into brightness buckets, then use that array of buckets to determine a brightness factor. Doable but probably complex and a lot of added code and I can't predict how that will look, it will probably result in a high brightness fluctuation depending on the animation.
My recommendation: use an adequate power supply for such LEDs or set the global brightness limit to 20% or so.

[Szabolcs2008]

your individual LEDs respond linearly to brightness

That is my bad, the non linear part is just bad wording from me. I meant to hint at how the current behaves when multiple channels are lit

It probably requires a binary search which is just not feasible.

Please correct me if I'm wrong, but imo it would be possible to take the average of the color channel brightnesses, so the ABL in the worst case scenario would only need to run the estimation 8 extra times per frame to get the limited brightness. (of course losing some estimation accuracy in the process). Binary search is probably inevitable though.

AI tools are definitely very bad when it comes to math and numbers

Yeah I can see that when looking at the code it gave me...

---

Also, I have written a fairly close estimation in python (~+10% error, which is probably alright and could be tuned), though it is still somewhat complicated and can't properly handle all 3 colors being lit simultaneously (up to ~+45% error) (python code is here). I know c++ enough to be able to implement this somewhat decently. I do not know how my code would perform as I'm definitely not the most experienced c++ developer. Should I try to do so and test it on real hardware?