LEDs are too bright for many applications such as wearables or where power is limited.
The solution is to use the FastLED.setBrightness() function to dim them down. But using software to dim an LED reduces the bit depth from eight bits to four or five. That brings down the original 256 levels to 16 or 32, reducing dynamic range, making small changes in brightness seem to flicker. This effect is from hardware limitations of the LED driver chip, not the fault of FastLED.
The other solution is to dim the LED in hardware, leaving all eight bits of brightness. That was the theory at least. Here are the results.
Details
This video demonstrates the difference between software and hardware dimming. The first LED is dimmed with hardware. The second LED is dimmed with FastLED.setBrightness(15). Notice how the second LED flickers.
I setup two WS2801 chips. The one on the left is dimmed down in constant current mode, which is adjustable, as in figure 6 from the data sheet. RXFB, the blue potentiometer on the left, is 350 ohms between XFB and ground.
The second LED is at full brightness, constant voltage, figure 7 from the data sheet. XFB is grounded in this mode. I think that this is the mode that most WS2801s use, maybe because it saves three resistors per RGB LED.
Even though this chip does RGB, this test has only the R channel connected. In both cases RL is 100 ohms between power and the LED.
The only time I use the LEDS.setBrightness() is in the setup() area of my Arduino programs. I use it to clamp the whole project to a predetermined max brightness because, like you said, most of the time full brightness is way too bright!
I think that the reason you are getting a choppy fade is due to the use of the brightness function to fade, 255/15 = 17 steps of fade. You can almost count the individual steps in the video. I could be wrong?!?!
@Jon_Burroughs You are exactly right. There are so few steps that you can almost count them. I dimmed down to 15 to make the effect obvious. Even dimmed down to that, the brightness could still be too high for a large number of LEDs in a dark place to be subtle.
The point of the exercise is to demonstrate the effect, because when you look at only the high level code, you wouldn’t know it happens. Without this effect, there would be no reason for dim LEDs. Without a reason there is no demand. Without demand, there would be no reason for somebody like @Tod_Kurt to want to make any.
There’s a third way, which @Mark_Kriegsman has worked out in theory (and extra overhead practice) and I’m working out the 0 extra overhead practice - which we will have more on shortly possibly
Ah… temporal dithering? Sounds messy. Pulse width modulating a device that itself pulse width modulates, that was originally designed so that you wouldn’t have to pulse width modulate. Yikes. I hear it does work well. It would be nice if it worked well enough to be able to gamma correct.
It’s not quite a pwm of pwm (though that is something that fadecandy does, which is why it limits strips to 64 rgb LEDs, because it wants a 400fps rate). Can’t wait until it is show-offable.
This is great, and clearly shows the steps using one method over the other. I can set a fade along a strip and turn down the brightness with setBrightnes() and watch the lower LEDs simply turn off. It’s not ideal, but it’s what’s available to work with.
The unfortunate part here is that doing hardware fade with ready made LED strips will be nearly impossible. You’re pretty much looking at having to design your own.
@Ashley_M_Kirchner_No I’m working on an RGB demo of the same thing. The problem is much worse in full color.
I’m thinking of a hack to the ready made WS2801 strings. They have current limiting resistors, since they don’t configure the chip in constant current mode. That might be an opportunity. Maybe swapping out the current limiting resistors for higher values would do the same thing, even if it’s totally tedious and wastes power.
I need to get some surface mount resistors to play with.
I already know that putting the right resistors between ground and the pins designated by the datasheet will do what I want, but there is nowhere on the ready made string to do such a thing. I tried cutting those pins away from ground to float them. That doesn’t work.
That’s the biggest issue here, having to retro fit those strips. After all, they are made rather cheaply. The same goes for the LPD8806 strips, they are essentially clamped at 18mA and will need hardware hacking to change.
Not going to say impossible, but rather difficult. Flex circuits are also still rather expensive. An up-to 50mm x 50mm two layer piece will run you $58.50 where the same as a rigid PCB is $9.90 …
This does make me wonder though … since I am making my own (rigid) strips for my POV batons, I can wire the IC different so I can control the current output with an external resistor. If I make it a digitally controlled potentiometer, that would mean I can do my own fading. Hrm.
This was the hope for the TM1829 - which allows for setting the base current used by each rgb pixel separately from the pwm value (32 levels of current setting). I haven’t played with them a whole lot yet, and it’s unclear how the current adjustment would fit into the setBrightness (it might not - current adjustment may be a different function that is nop’d for non-TM1829 chips - then there’s the issue of per-pixel value setting as well…).
Here is the RGB video: http://youtu.be/jjJsdtr7vbY
There are big hue changes during the software fade. The hue changes are much smaller during the hardware fade.
