I have been performing all sorts of tests with the shiftbrites and
have a lot of code written now for controlling it. However I am
getting odd performance from the actual LEDs and this has caused me to
do a bunch of testing on them.
For example, if I am using an arduino and the example code from the macetech site and I do a loop that will ramp the RED value of all the leds from
0 to 1023:
-At value of 1 the leds are on, dim but not that dim
-By value of 200-300 they are at full brightness and the remaining
values up to 1023 have no perceivable change.
I am assuming that PWM values from 0-1023 do not correspond to a
linear fade in light intensity? i.e. there is only a narrow range of
pwm values that actually result in perceived changes in brightness?
This behavior is dramatically affecting my algorithms for HSB and RGB
control when the led hues are not at full saturation and brightness.
Unless there's a really big problem with my shiftout routines, the actual intensity should be varying exactly as you would expect from PWM. However, the eye is pretty much an edge detector...when one of your rods or cones senses light, it sends a nerve pulse and takes some time to reset the charge. That makes higher PWM duty cycles appear to change less. I think that if you set a ShiftBrite to blink from 300 to 1000 you'd notice a significant change. But some kind of logarithmic scaling would definitely help make the brightness change appear linear.
I wish I had some more tips or code to offer you, but I haven't found the best solution yet.
yeah I did more research and this is something I have had to do in the past (but kind of forgot about )
The fact that the eye has trouble sensing gradual fades has been exploited to conserve power in lighted rooms. The smart lights will start at a certain brightness when you enter (motion detection) and then slowly dim without you perceiving this.
I looked on the allegro data sheet and the PWM register values correspond to linear change in duty cycle percentage. However as you know this does not correspond to perceived brightness ... would have been really cool if that function was built into the microcontroller but I guess it makes more sense to compensate for it in software.
I will definitely be making a lookup table of some sort of log/power values...
)