EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: beduino on October 31, 2019, 07:53:58 pm
-
Hello, Probably obvious thing for many, but I'd like to use CC (common cathode) RGB LED as indicator in cycling helmet,
so I'd like to avoid any flickering, but maybe smooth pulses at the rate of cadence (RPM of chainring) at computed colour.
Idea is to use discrete elements like NPN transistor, current limiting resistor but also inductor and maybe Shottky diode to provide something like buck converter for each Red/Green/Blue channel controled by MPU PWM ISR using 3 pins ?
No need for too many colours available, but I'd like to avoid LED flickering by changing LED current instead of manipulate RGB colour with high frequency PWM directly each Red/Green/Blue component.
As I said, no problem to make something like overkill in this application, to have nice steady shining RGB LED colours without any flickering...
I've WS2812B RGB LEDs, but unsure whether its light is flickering or not, since didn't setup experiment to verify this - additional issue is driving those leds using 1 pin require relative high frequency, which might be problem, since I'de like to put RGB LED without driving circuit maybe as far as a few meters away from MPU, do not sure if WS2812B RGB LED will work controled by longer wire :-//
Anyway, main concern is flickering in this application, since cyclict might have in sight light output from this RGG LED for a long time hours ride, so avoiding any flickering is a must, I think...
UPDATE: Realized that probably I need CA (Common Anode+) RGB LED to use capacitor in parallel to drive each RB channel directly from MPU with additional current limiting resistors.
NOTE: I've CC (Common Cathode -) RGB LED - it doesn't matter too much since I've implemented in MPU software CC RGB LED by default, but CA RGB LED can be enableld when needed.
Latest schematics without MPU (ATTiny85 8MHz ) below:
(https://www.eevblog.com/forum/projects/driving-cc-rgb-led-directly-from-mpu-without-flickering-using-3-pins-pwm/?action=dlattach;attach=868188)
-
I know it's not exactly what you asked but I really really like...
http://www.ti.com/product/LP5569 (http://www.ti.com/product/LP5569)
I've been playing with these recently and they are great fun. Talk to them via I2C, your MCU can even go to sleep whilst the effects continue.
Claims "12-Bit 20-kHz Internal Individual PWM Control Without Audio Noise"
-
I've been playing with these recently and they are great fun.
I'd like to be sure RGB LED will not flicker at high frequency.
Do you have some real experiment data to proove that?
Meantime, I've found on other forum that adding capacitor in parallel to LED smooth its current while driving using PWM.
I've already made simple simulation like below with 3mA green LED and it looks like it could work in my case, since I do not need blink this RGB LED at higher frequency than 3Hz, while we have quite nice steady LED current with 22uF capacitor @ 2.5kHz 25% duty cycle 8)
(https://www.eevblog.com/forum/projects/driving-cc-rgb-led-directly-from-mpu-without-flickering-using-3-pins-pwm/?action=dlattach;attach=865002)
Since, I've 10kHz MPU timer used to provide system time updated in 100us intervals, I could use it for 2bit PWM: 0% 25% 50% 100% which means I should be able get 4*4*4=64 RGB colours which is fine in this application, I think.
Now, it is time to implement this PWM idea at the end of 10kHz timer ISR and in main code do some tests by using only one byte to store RGB 64 colours on 6bits and maybe use free 2 MSB bits to store something like 4 step dim level adjustable by using a few switches additionally limiting CA (Common Anode+) RGB LED current when needed :-/O
NOTE: Blinking at 0Hz-3Hz will be controled based on I2C sensors data and has nothing to do with PWM flickering.
What do you think about this capacitor in parallel to LED to make PWM current more stable to avoid flickering?
-
"while we have quite nice steady LED current with 22uF capacitor @ 2.5kHz 25%"
Most normal people wouldn't notice the 2.5kHz PWM even without the cap. I'm using a 2.3kHz LED desk lamp ATM. I think the cap could be a lot smaller than that maybe even as low as 0.2uF, anything that smooths the edges of the PWM helps to make it a bit less noticeable.
-
WS2812 is ~400Hz PWM frequency, but you can get other devices with higher levels: SK6812 1.2kHz, APA102C 20kHz.
If you drive at 5V I'm sure 1M or so cable would be ok, but would want some ESD mitigation.
-
"while we have quite nice steady LED current with 22uF capacitor @ 2.5kHz 25%"
I'm using a 2.3kHz LED desk lamp ATM. I think the cap could be a lot smaller than that maybe even as low as 0.2uF, anything that smooths the edges of the PWM helps to make it a bit less noticeable.
Thanks, nice to know there are desk lamps with similar PWM frequency I've choosen in my Attiny85 MPU :-+
However, when we are talking about capacitor, what I noticed during simply simulation of circuit showed above in one of my posts, while I was trying different cap & led type combinations - I mean I've assumed for red 2.0v, green 2.1V and blue 3.6V, to provide ~3mA maximum current @ PWM 100% different current resistors needed, so idea is try rather adjust for each RGB LED component capacitors to have similar RC time constant or maybe even something more complicated, based on circuit simulation, while we have LED in parallel to capacitor - especially in the case of blue (B) component where 3.6Vf is ~70% higher than for green 2.1Vf, which means smaller current limiting resistor needed for blue component than for red or green ::)
Whatever we do in this simply MPU based RGB LED driver on its 2bit PWM, it will not be such sophisticated like in some LED drivers where we can set those currents eg. via I2C at 256 levels.
Anyway, I think, we have to take care of choosing different caps for blue RGB led channel, than maybe similar for red and green ???
While I've already ready AVR Attiny85 MPU ISR 10kHz timer down to 2.5kHz PWM software, I should be able to play with real circuit, based on some measurements of real RGB LED Vf @ 3mA to try different capacitors, but I think @ 2.5KHz we need at least 10uF (22uF looks good for red/green channels) to fit into one of my requirements - I do want LED current not oscilating too much.
Since, I think I do not need more than 3mA per RGB LED channel, maybe this simply concept with capacitor in parallel to LED will work for 64 colours :-/O
-
I realized, that I might need 3bits instead of 2bits to have RGB LED driven by PWM: 0% 25% 50% 75% 100% , so while we have 10kHz MPU timer ISR divided by 5 we get quite nice 2kHz PWMs for each RGB channel and RGB colour change is as simply as it is, where synchronization with ISR and translation from 8bits 0..255 -> 3bits 0..4 is hidden in ISR & led_rgb_set interface function 8)
(https://www.eevblog.com/forum/projects/driving-cc-rgb-led-directly-from-mpu-without-flickering-using-3-pins-pwm/?action=dlattach;attach=865890)
Custom RGB LED MPU software implemented - now time for some fun to test different capacitors & current limiting resistors :-DMM
-
I've managed bloody breadboard to create circuit with capacitors in parallel to RGB LED, but probably it could be faster to... draw PCB tracks manually on sheet of copper and to etch rather than messing with wiring |O
I've common cathode (-) RGB LED, but it is not the problem and waveforms above works fine with capacitors 22uF-33uF.
However, complete disaster is... lighting pattern from this bloody 5mm RGB LED - so bad that one can see magnified indyvidual red, green, blue small dots instead of mixed RGB colours :o
Anyway, we never giveup and idea is to use somekind of fiber (5mm inner diameter ???) to guide light comming from this RGB LED in the hope it will better mix RGB components?
Benefit could be we can have compact PCB with RGB diode close to MPU and fiber as long as needed to provide RGB LED light where needed to be displayed closer to human eyes, because of at the moment is useles from short distance :palm:
Any ideas howto mix those bloody RGB led visible dots into something we could call RGB colour? :-\
-
You may be running into an issue with the Moire effect from conflicting timers if you're seeing flickering.
Normal PWM above the frequency you can reliably see will blur into an averaged color - the speed of your eye's response to color acts sort of like a low pass filter - but if you run PWM drives from different clock sources (or any one not synchronized with the same divider/ratio), you can get flickering of varying speeds based on the different PWM signals not being aligned. If you're familiar with radio frequencies or audio tones interacting, this is basically an optical mixing product of the two frequencies that folds over and manifests visually at a low frequency pulsation. For example, if you have two PWM pins on a 16 bit counter and one on a 14 bit counter, even if you set all of them to 50% duty cycle, if they're driven by the same clock, the actual switching will be happening at different times, and the 14 bit counter will go through four cycles before the 16 bit counter rolls over. You can fix this by locking the internal timers or just choosing PWM pins that are driven by the same hardware timer.
Provided your PWM frequency is high enough, a few hundred Hz will do fine, even without any filtering the outputs will appear smooth and steady. You can't smooth out the PWM signal too much, either, because the minimum voltage to turn on the LED is fixed, so if you smooth out the PWM to be a slow analog control signal, the LED will just be off for dim values of any color.
-
You may be running into an issue with the Moire effect from conflicting timers if you're seeing flickering.
Flickering is not an issue there, since I've capacitors in parallel to RGB led channels - I will attach current circuit schematics later and maybe video what I'm talking about.
Problem is 5mm RGB led light pattern is useless to watch from short distance without additional optical cover, so that is why I thought about optic fibre - for example pipe 5mm diameter to guide light comming from this LED and hope reflections on sides of this pipe will make visible light more uniform accross diameter ::)
Anyway, PWM is controlled by one 10kHz timer where internal ISR counter overflows after 4, so divide by 5 we have 2kHz nice PWM I've showed above.
-
Provided your PWM frequency is high enough, a few hundred Hz will do fine, even without any filtering the outputs will appear smooth and steady.
Probably red (R) channel is faulty in this CC RGB LED, since no chance to get nice red light spot - instead red ring apears and while trying to get yellow by mixing with green (G) I can see in the dark on white room ceiling slightly yellow only where this bloody red ring apears instead of smooth yellow intersection :palm:
I've made this test without any MPU, just by connecting to VCC 4.1V instead of MPU PWM pins output, so PWM is not issue there for sure.
I will try another RGB LED, since measured Vf voltages and calculated each RGB channel currents and they are close to designed value ~3mA:
(https://www.eevblog.com/forum/projects/driving-cc-rgb-led-directly-from-mpu-without-flickering-using-3-pins-pwm/?action=dlattach;attach=868192)
Latest circuit schematics I've already updated in my first post in this thread attached below, to show those caps in parallel to CC RGB LED channels to stabilize quite nice RGB LEDs current @ 2kHz PWM:
(https://www.eevblog.com/forum/projects/driving-cc-rgb-led-directly-from-mpu-without-flickering-using-3-pins-pwm/?action=dlattach;attach=868196)