I’m looking to iterate on an [LED strip project I’ve done previously. One thing I’d like to do is increase the resolution of the PWM control, as with the 8-bit control built into an Arduino (/ATMega), the steps on the low end tend to be very noticeable. Do dedicated PWM controller chips exist, and could someone help me find them? Currently looking through Digikey, but there are just too many IC categories…](Headboard Lights - SerialHobbyists Wiki)
Heh, I actually ran across that one on Digikey; not sure how I missed it on Sparkfun. I’m thinking about giving it a shot, but it’s also a constant-current driver. I just need something that can provide a logic-level output that can control an external MOSFET driver (need way more current than the TLC5940 can sink). Any such thing?
Try changing the PWM values nonlinearly. I built a light to simulate sunrise and I found that it looked best with small 1 bit increments on the low end and much larger increments as the light level rose. It wasn’t quite logarithmic, but close to it. Human vision is nonlinear and very sensitive at low light levels, but with only 100 steps I was able to get a pretty smooth increase. Tried to find the code for it but that project is long gone 
I know there are other PWM ICs in the TI TLC59xx family but I think they are all OC/OD type outputs. I'm not sure how available these are but they could drive a FET directly.fornax:
Heh, I actually ran across that one on Digikey; not sure how I missed it on Sparkfun. I’m thinking about giving it a shot, but it’s also a constant-current driver. I just need something that can provide a logic-level output that can control an external MOSFET driver (need way more current than the TLC5940 can sink). Any such thing?
http://www.nxp.com/documents/data_sheet/PCA9685.pdf
http://cds.linear.com/docs/en/datasheet/8500f.pdf
If you’re doing onesies - twosies perhaps they might send you a sample.
As for human discernable brightness levels, lyndon is right. Depending on who you read, humans either see logarithmically or according to square law. One article I recall said it was both, one at dim levels and the other at bright levels. I don’t recall which was which. That’s why monitors and TVs have gamma correction.
http://en.wikipedia.org/wiki/Gamma_correction
I think you can get ~20 evenly spaced (per human vision) brightness levels from a 8 bit/256 linear step PWM. It does make you wonder why someone doesn’t put that into silicon and offer an IC to drive LEDs (or LED drivers). Perhaps even w/a programmable gamma factor. IIRC a gamma of either 1.8 or 2.2 is considered standard.
Thanks for the responses. If you peruse the project page I linked above, you’ll see I’m already gamma correcting for the non-linear response of human vision. Trouble is, on the low end even changing brightness by a single unit (e.g. from 2 to 1) is quite noticeable if you’re doing a slow fade, like a sunset effect. There’s nothing you can do in programming to help that.
Mee_n_Mac:
I’m not sure how available these are but they could drive a FET directly.
Thanks for those! I don’t think I’ll be able to work with the LT8500 (looks like it only comes in QFN). The PCA9685 at least comes in TSSOP. I haven’t worked much with surface mount, but I gotta start sometime. I’ll see if I can source them.
Aaarrgghh ... I had read your (well documented) project page and then completely forgot about it by my 2nd post. I'm blaming that on eggnog ! Now that you've stirred my brain cells I have 2 less intrusive potential solutions for your consideration.fornax:
Trouble is, on the low end even changing brightness by a single unit (e.g. from 2 to 1) is quite noticeable if you’re doing a slow fade, like a sunset effect. There’s nothing you can do in programming to help that.
First is to realize that the 328 MCU you’re using has a 16 bit timer and so has 2 pins capable of doing 16 bit PWM. I wonder, given that the eye is less sensitive to blue, if you couldn’t get acceptable intensity steps w/o too much color shift using the two 16 bit channels for R and G and sticking w/8 bit for blue. You would have to set registers directly and any pre-canned Arduino functions using that timer would have to be avoided, but for the price of changing a few connections and modifying the software …
http://arduino.cc/en/Tutorial/SecretsOfArduinoPWM
Also worth a mention is a swap to a 32U4 MCU. It has two independent 16 bit timers and supposedly can do the 3 channels of 16 bit PWM. Again you’ll have to write to registers vs using the analogWrite() function.
Mee_n_Mac:
First is to realize that the 328 MCU you’re using has a 16 bit timer and so has 2 pins capable of doing 16 bit PWM. I wonder, given that the eye is less sensitive to blue, if you couldn’t get acceptable intensity steps w/o too much color shift using the two 16 bit channels for R and G and sticking w/8 bit for blue.
Ooo… I didn’t know about that capability. Yeah, I think sacrificing blue resolution is probably acceptable, as we mostly are doing sunrise/sunset stuff primarily in red. Definitely worth some research.
Thanks for the info! I’m going to grab a couple of PCA9685s from Digikey to play with, too. Options are always good. Will revisit this thread down the line after I’ve had some time to play.
One other thought to minimize color shifts using only 8 bits for blue, especially at low intensities. You can do (perhaps) what a lot of TN LCD panels do … frame rate control (FRC). Say you needed 1.5 bits of blue to get exactly the desired color. If your loop() runs fast enough then you could have 2 bits on one cycle and 1 bit on the next. Your eye will average the colors to something inbetween. You have to decide just how far to carry the dithering, 1/2 bit or 1/4 bit or … That will depend on keeping the FRC cycle and PWM rates fast enough to not be seen as flickering.