# Why Multiplexing the LED

Why Multiplexing the LED
Introduction:

The plate is made of 32 * 32 = 1024 LED lights (voxels). These LEDs cannot be controlled all at the same time:

or we would need 1024/8 = 128 tricolor LED drivers, which we would be much too expensive.

with a current of 20mA per LED,  if all the LED’s are white at the same time, there must be a power of 1024 * 3 * 0.02 = 61A (does not exist at Farnell).

LEDs will be temporally multiplexed: they will be divided into groups of n G LED (G and integer n, with n = G * 32 * 32) and each group will be lit for each turn 1/Gième time.

Consequences:

● The maximum average intensity of LED will be divided by G

● there must be a cycle time between group fast enough to scan the eye is not noticeable. According http://en.wikipedia.org/wiki/Flicker_fusion_threshold the perception threshold is around 60Hz (in peripheral vision, in central vision it’s lower). We therefore choose a refresh rate higher than 60Hz. (which is assure because our leds refresh at 4096 Hz (16 image with 256 position each)

Results:
If G = 8 -> there should be a supply of 61/8 = 7.6 A
A diet of this type exists in Farnell http://fr.farnell.com/elc/ale1210/alimentation-ajustable-10a/dp/4916128

Data flow analysis:

Between the SD card and the gumstix / / gumstix and the FPGA:

• This is the rate that will be required to display real-time images HARP.
Knowing that we have to light 32 * 32 LEDs each with 8 bits of color information.
It is also 16 frames per second and 256 positions of the plate to display an image.
What we need is a flow 32 * 32 * 8 * 16 * 256 = 32Mbit / s for the data flow between the SD card and the gumstix
If we take an SD card class 10 we theoretically have the data flow of  80 Mbit / s.
Flow between the SD card and the Gumstix is ​​assured
• This flow is also needed between the gumstix and the FPGA.
After having talk to member of the Roseace project http://roseace.telecom-paristech.fr/
We learned that they were able to get a data flow between the gumstix and fpga up to 40 Mbit/s
Flow between  the Gumstix and the FPGA is ​​assured

Between the FPGA and the two RAM:

• Our Architecture is based on Two RAM, so that we can write in one RAM while reading the other one
So 32Mbit / s data flow in writing and reading for each RAM is what we need.
The Ram we have chosen is aligned on 16 bits (16 bits per address) and has an access time of 10 ns.The plate stay at the same position during 1/(256*16) = 244140,62 ns
We need to do (in the worst case) 32*32 access to the RAM so it will take 32*32*10= 10 240 ns which gives us plenty of time to get the data and then display them.
Flow between  the FPGA and the RAM is ​​assured

Between the FPGA and the LED drivers:

we have to control a matrix of 8*8 RGB LEDs with a LED driver.
Knowing that we need to control these 8 * 8 leds for a plate position that is to say for 1 / (16 * 256) = 244 microseconds
There are 8 lines to display at each position so that time is divided by 8 to determine the flow rate required for a line. = 30 microseconds.
During that time we have to send 8 * 24 color information for the 8 voxels (in fact each voxel needs 24 bits for its configuration).

so we have 192 bits every 30 us which is 3.66Mbit / s

We learned that drivers were able to get a data flow up to 30 Mbit/s
Flow between  the FPGA and the drivers is ​​assured

Between the FPGA and the incremental encoder:

We must be able to know the position of the plate 16 * 256 per second, it gives us a rate necessary to 4kbit / s.
A serial port will be enough.
Flow between  the FPGA and the incremental encoder is ​​assured

Between the FPGA and the multiplexer:

flow is required at least 16 * 256 * 8 because it requires that for each position of the plate we pilot 8 lines.
So we need to 32kbit/s rate.
Flow between  the FPGA and the multiplexer is ​​assured

That end the analysis of data flow.

The HARP group.

Alexandre Blanchet

### 2 comments to Why Multiplexing the LED

• Felix

“Flow between (…) is assured”
Personally I would avoid using the word “assured” until I see it working for real 😮

Otherwise, have you tested the SD card reader? Because the SD card is NOT the only limiting part of the equation.
For the 40Mb/s between the Gumstix and the FPGA be aware that it’s a raw transfer rate result, no protocol, no command, no context switch or whatever.

And you really gonna use only 8bits per pixel ?!

• There are many pitfalls in this post. Let’s talk about it together tomorrow !