adafruit / Adafruit_DotStar

GNU General Public License v3.0
98 stars 58 forks source link

Decision to ignore brightness is wrong, you just killed high dynamic color range #5

Closed niteris closed 9 years ago

niteris commented 9 years ago

Here is the comment in the cpp file:

Although the LED driver has an additional per-pixel 5-bit brightness setting, it is NOT used or supported here because it's a brain-dead misfeature that's counter to the whole point of Dot Stars, which is to have a much faster PWM rate than NeoPixels. It gates the high-speed PWM output through a second, much slower PWM (about 400 Hz), rendering it useless for POV. This brings NOTHING to the table that can't be already handled better in one's sketch code. If you really can't live without this abomination, you can fork the library and add it for your own use, but any pull requests for this will NOT be merged, nuh uh!

I think this is misguided. We led artists/programmers are trying to implement high-range brightness control and we don't need the high-speed PWM. In fact, I would reason that the number of people that need the high-speed PWM for POV projects is in the single digits. Most artist/programmers that I know are programming light strips that are more or less stationary.

All of us with stationary strips have the same problem - we can't get dim pixels. Having a brightness control would solve this problem.

Hypothetically, think what would happen if the brightness pixel was used - we stationary strip users would get high dynamic range for the LEDs, and the POV people would get their POV feature if they set the brightness to 255.

PaintYourDragon commented 9 years ago

The 5-bit dimming control on the APA102 (DotStar) is just a logical AND between the high-speed (~19 KHz) PWM and a lower-speed PWM signal that's generated off the same clock with a prescale (1:32, so actually closer to 600 Hz and not 400). It's not the same as the "current control" available on some higher-end LED driver ICs and does not actually provide additional dynamic range (due to the prescale, it will always be an exact division and equivalent values at full brightness are always available; there's no frequency mixing to provide new duty cycles not otherwise available).