Why Multiplexing the LED
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.
● 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)
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
- 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.