LED scan frquency

M

Mike Garner

Guest
I am at the design stage of a visual effect which will comprise 25
squares, each with a red, green & blue LED, driven by a
microcontroller to achieve different colour mixes.

Initially, I am thinking of connecting the LEDs in a "row/column"
arrangement, using 3 power MOSFETs to drive the anodes of the
red/green/blue "rows" and driving the cathodes of each square
("column") through a 74HC595/ULN2803 combination (with appropriate
resistors for each LED). The idea is to load the data serially to the
HC595s, light up that row, then onto the next etc.

I was thinking of a scan frequency of 70Hz to prevent visible flicker
but this is where I'd appreciate your comments.

My initial thought is to use an 8 bit counter, counting down from 255
to 0 and comparing this to a preprogrammed value for each LED. If the
value is <= the count then we light up that LED. I've prototyped this
for 1 "square" (using 1x red, 1x green & 1x blue LED) and it works
well.

If I scale this up to 25 squares, I get the following result - 70Hz
scan x 3 colours = 210Hz row scan frequency. If each colour has 256
possible brightness settings, this equals 53,760 shift register
"loads" per second (which is quite high but not unachievable).

1. Is this calculation correct?
2. Do I need to scan at 70Hz?
3. Is there a better way of doing it?

Thanks,
Mike
 
On Mon, 28 Feb 2005 19:24:56 +1300, Terry Given <my_name@ieee.org> wrote:

yea the calculation is correct. Fred's point about the effect of MUXing
on available duty cycle is highly relevant. I do work for a company that
mnakes full colour high-res LED video screens (the first one had
1,500,000 LEDs and 10,000,000 smt parts :).
I worked on some modules with 3mm dia. tri-color LED pixels (you can see the
tiny dies mounted exactly adjacent to each other within the encapsulated pixel)
on a 4mm and 5mm pitch set into a 16x16 stackable pixel array. These included
heatsinks on the back, black interpixel finish on the front, and each used six
graphics controllers with ram and constant current drivers.

Each controller handled an 8x16 array of single-color dies within the pixels.
Three driver ICs were responsible for the "upper half" and three for the "lower
half," with one for each color. Each included a 7-bit settable "course" and a
7-bit settable "fine" (with its max at 1/2 of the "course" source and simply
added in parallel) pair of constant current sources that set the "100%" level
and could accept a 5-bit PWM number to control the brightness of each color die
it controlled, from there. A programmable stagger of the column drivers allowed
for reduced EMI. There was also some color "bleed" controls, as well.

Separate voltage sources were recommended for each color, because of
dissipation. If you set up all of the voltages to the minimum required for the
blue LEDs, then the red LED constant current drivers would dissipate more heat.

I'd imagine that units like this must greatly simplify the production of the
kinds of LED video screens you are talking about. Did you use these kinds of
things? (I've still got a bunch of them in a box, here.)

Jon
 
I read in sci.electronics.design that Don Klipstein <don@manx.misty.com>
wrote (in <slrnd25il6.k3m.don@manx.misty.com>) about 'LED scan
frquency', on Mon, 28 Feb 2005:

Personally, I see flicker sometimes at 60 Hz and have yet to see
flicker at 72 Hz.
Flicker perception depends on the relative brightness of the source
compared to its background. Above 60 Hz, the curve is VERY steep. You
need a large increase in brightness even at 65 Hz to see the flicker.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
 
Jonathan Kirwan wrote:
On Mon, 28 Feb 2005 19:24:56 +1300, Terry Given <my_name@ieee.org> wrote:


yea the calculation is correct. Fred's point about the effect of MUXing
on available duty cycle is highly relevant. I do work for a company that
mnakes full colour high-res LED video screens (the first one had
1,500,000 LEDs and 10,000,000 smt parts :).


I worked on some modules with 3mm dia. tri-color LED pixels (you can see the
tiny dies mounted exactly adjacent to each other within the encapsulated pixel)
on a 4mm and 5mm pitch set into a 16x16 stackable pixel array. These included
heatsinks on the back, black interpixel finish on the front, and each used six
graphics controllers with ram and constant current drivers.

Each controller handled an 8x16 array of single-color dies within the pixels.
Three driver ICs were responsible for the "upper half" and three for the "lower
half," with one for each color. Each included a 7-bit settable "course" and a
7-bit settable "fine" (with its max at 1/2 of the "course" source and simply
added in parallel) pair of constant current sources that set the "100%" level
and could accept a 5-bit PWM number to control the brightness of each color die
it controlled, from there. A programmable stagger of the column drivers allowed
for reduced EMI. There was also some color "bleed" controls, as well.

Separate voltage sources were recommended for each color, because of
dissipation. If you set up all of the voltages to the minimum required for the
blue LEDs, then the red LED constant current drivers would dissipate more heat.

I'd imagine that units like this must greatly simplify the production of the
kinds of LED video screens you are talking about. Did you use these kinds of
things? (I've still got a bunch of them in a box, here.)

Jon
Hi Jon,

the later ones use LED driver chips, less solder joints that way. Our
first screens were entirely discrete. Separate supplies for blue/green
and red. all running from +48Vdc, via a nice little planar smps.
Efficiency is a big issue - especially at 25kW or so.

Cheers
Terry
 
Spehro Pefhany wrote:

The sensors in peripheral vision are "faster". It's easy to perceive
irritating flicker that disappears when you look straight at it. If
you have a CRT monitor, try looking sideways relative to the screen.
Presumably an evolutionary adaptation that helps you perceive things
coming at you fast from the edges of vision...
So true- I am always being irritated by peripheral vision flicker- but
it may be more of a necessity for maintaining balance than an
evolutionary adaptation.
 
I read in sci.electronics.design that Spehro Pefhany <speffSNIP@interlog
DOTyou.knowwhat> wrote (in <lk9621tvb9k9nobr3i2p7uve7af4ebogcg@4ax.com>)
about 'LED scan frquency', on Mon, 28 Feb 2005:

The sensors in peripheral vision are "faster". It's easy to perceive
irritating flicker that disappears when you look straight at it. If you
have a CRT monitor, try looking sideways relative to the screen.
Presumably an evolutionary adaptation that helps you perceive things
coming at you fast from the edges of vision...
Yes. In the same vein, sounds from behind provoke a stronger reaction
than those from the front. Discovered in early stereo-via-headphones and
binaural recording experiments.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
 
sounds from behind provoke a stronger reaction than those from the
front.
==================================
This is proof of Darwins theory of natural selection. The cavemen that
didnt hear the saber toothed tigers sneaking up behind them didnt get
their gene for acute hearing sensitivity selected....
 
I read in sci.electronics.design that BobG <bobgardner@aol.com> wrote
(in <1109614178.167450.136800@o13g2000cwo.googlegroups.com>) about 'LED
scan frquency', on Mon, 28 Feb 2005:
sounds from behind provoke a stronger reaction than those from the
front.
==================================
This is proof of Darwins theory of natural selection. The cavemen that
didnt hear the saber toothed tigers sneaking up behind them didnt get
their gene for acute hearing sensitivity selected....

Yes, of course; it's clearly a survival trait.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
 

Welcome to EDABoard.com

Sponsor

Back
Top