At max brightness, is there any POV trickery library to simulate more than 256 hues on Analog 5050 led strips? I should think that with a fast enough of a refresh I should be able to get 1024 at least.
Thanks
Dimitri
At max brightness, is there any POV trickery library to simulate more than 256 hues on Analog 5050 led strips? I should think that with a fast enough of a refresh I should be able to get 1024 at least.
Thanks
Dimitri
May i start with asking why you would need more than 256 brightness values? You could always write your own pwm code that's plenty fast for making more brightnesses, but i'm wondering what you would use it for :).
Do you seriously imagine you could distinguish more than 256 hues?
I think not.
The only problem with PWM in general is gamma. This applies to the overall intensity such that steps at the lower intensities need to be much finer.
What I am trying to do is map a range of values coming from a sensor. These values have a range greater than 256 and while I know I can normalize the data to 256, there are times when the sensor reads values that vary no more than +-2 and I would like to see some indication that there is streaming data.
@Paul__B
Your point is well taken... do you have any suggestions for schemes representing a data stream like this that might incorporate brightness levels as well so that more "animation" to the data can be observed while still remaining intelligible?
Thanks to you both
Dimitri
It's possible to program the pwm registers / timers and use pwm resolution up to 16 bit. Could match the resolution to the sensor ... would take a re-write of library(s) and code.
Not addressing the gamma problem directly, but I made a suggestion for executing low PWM duty cycles here.
Technically using gamma correction is incorrect as it's not used to correct for human perception o f brightness but to correct the nonlinearity of applied voltage versus generated luminance by an CRT (Cathode Ray Tube).
The correct way to calculate the curve is actually according to CIE LAB 1976 as outlined by this Wikipedia article.
Coincidentally the difference between these two correction curves is not likely to be visible in normal LED lighting systems so the argument serves a more academic point in this case. It just bugs me when that gamma correction incorrectness is repeated at major sites such as the Adafruit site that propose to serve an educational purpose. In that case it should be corrected!
I believe if you are only worked about a single LED or several LEDs in series on a single LED driver and only need PWM from one pin, in that case one of the timers on a normal Arduino can be programmed to generate a 16 bit PWM signal and there several online resources available.
My personal preference are Teensy boards that have many 16bit pins and Arduino library fnctions that allow to manipulate resolution and PWM frequency easily and over a wide range.
Headroom:
Technically using gamma correction is incorrect as it's not used to correct for human perception o f brightness but to correct the nonlinearity of applied voltage versus generated luminance by an CRT (Cathode Ray Tube).The correct way to calculate the curve is actually according to CIE LAB 1976 as outlined by this Wikipedia article.
I shall try and keep that in mind. O0