You need 10 bits to see a LED ?
Are you sure you'll be able to see that difference, or do you need it for something else than a human eye to see the difference ?
MAS3:
You need 10 bits to see a LED ?
Are you sure you'll be able to see that difference, or do you need it for something else than a human eye to see the difference ?
Its very easy to see the difference at 8 bits. Not at the brighter values (253, 254, 255) but at the dimmer ones (0, 1, 2 etc). At 10 bits it should be less noticeable.
You could use a PCA 9685 but if that makes sense depends on what LEDs you are talking about.
@MAS3
If the application requires slow, brightness corrected dimming to low light levels, then you need 10 bit PWM resolution.
I've experimented with this quite extensively for my own lighting systems @ trippylighting.com
Well, you were handed some sugestions.
Did you check out Headroom's suggestion, perhaps in a module (click !) ?
State your definition of 'cheap' if that is not what you're looking for, please.
Maybe this could be done by software PWM? I've been using the Palatis softPWM library and have the same problem with the steps between the dimmer values being too visually distinct. I've tried modifying the library to allow for more brightness levels than 256 without success and I don't have enough understanding of how the library works to know if this is even possible.
Software PWM to 16 bits would require the sketch to time periods shorter than 1us, to avoid flickering (i.e. assuming refresh rate of over 50Hz.) 50Hz is a period of 0.02s, so PWM pulses would need to be 0.02 / (2^16) which is 0.3us. The micros() function can only time down to 4us, so I don't know if 16 bits could be achieved. I think 12 bits could be achieved
You can employ a trick when fading leds called Bit-Angle-Modulation (BAM). This is not strictly PWM, because, for example, it would not work with servos. BAM would still be limited to 12 bits, for the same reasons, but it is more efficient which means the Arduino has more processing time available for other things while the fading is being performed.
I don't know if there is an available library for doing BAM, but I could probably advise how to code it into your sketch.
Another solution is to simply not use an Arduino UNO. I've moved all my efforts over to the ARM based Teensy boards for pjrc.com years ago.
Smaller, cheaper, much more processing power.
Even the least capable Teensy LC utilizes an Arm Cortex M0 and easily outperforms an Arduino UNO at $11.65
The Teensy boards are fully Arduino compatible and the Teensy LC already has 10 PWM pins with up to 16 bit resolution, easily configurable to use different resolutions and frequencies.
In a current project I am using 7 of these PWM pins on a Teesny LC also for super smooth, brightness corrected RGB led fading. Works like a charm!
PaulRB:
I don't know if 16 bits could be achieved. I think 12 bits could be achieved
I'd be happy with even a small increase over the current 8 bits I have to work with.
PaulRB:
You can employ a trick when fading leds called Bit-Angle-Modulation (BAM).
Thanks for the tip! That looks promising. It would certainly be nice to also be able to run at a higher frequency to reduce flicker. I'm currently limited to around 100Hz which is acceptable but could be better.
PaulRB:
I don't know if there is an available library for doing BAM, but I could probably advise how to code it into your sketch.
I'd probably want to create an API similar to that of the Palatis softPWM library for my application(15 channels on ATmega328P @ 8MHz).
My current workaround for this issue is to never allow any LED to go below a minimum brightness level(8) below which the difference between brightness levels is too distinct. So all the LEDs are always dimly on.