Making an interractive LED table, any ideas on how to make it cheaper/more simple?

The idea is to fill a table with 1024 RGB leds a long with some hundred IR phototransistors to detect movement and distance above the table. Our cheapest and best option on how to actually accomplish this is to use butloads of attiny88s (cheapest atmel price/pin I could find) to PWM control each LED as well as read the signal from the phototransistors. These attinys will act as I2C slaves which will be controlled by one or several I2C masters. Does anyone have any thoughts on how this will play out? Is it possible to make things cheaper and/or more simple? Also, we are thinking of just ordering a bunch of cheap 5mm RGB leds from ebay and expect crappy quality, but how crappy are they really?

Sounds complicated and if you intend to run one I2C bus around them all you will run out of addresses, bus drive capacity and speed.

What are the IR phototransistors detecting? Most need a fairly 'bright' IR source before they give significant changes in their current and that current has to be detected somehow.

Cheap RGB LEDs can be just as good as ones sourced from a reputable supplier. The difference in the quality control and testing they go through. Having used hundreds of 'cheap' RGB LEDs, the biggest problem I found was their radiation pattern, the die didn't align with the axis of the lens so many of them 'squinted' to one side. The focus of each color was also a little unpredictable, the three light beams are slightly out of line with each other and any misalignment with the pins resulted in rotation of the light pattern. Ones sourced from a good manufacturer and distributor will have better controlled parameters. So "your mileage may vary", you could get a good batch or you could get a bad one. The chances of getting a bad one replaced through Ebay are slim!

I'm not sure what your design is trying to achieve but if asked to make a matrix of 32 x 32 (=1024) LEDs I would look at multiplexing rather than 1024 individual circuits.

Brian.

I would need two I2C busses then probably, perhaps three if the refresh rate gets too slow. The table is going to have a bunch of IR-leds as well so that the fototransistors can have something to pick up on.

Multiplexing crossed my mind, but I was unsure about what light output that could be gotten from it? Would the leds mind having 32 times it's rated current for 1/32 of the time? How high should the frequency be to avoid LED damage?

The I2C problem relates to how you select an individual driver. There are 127 possible I2C addresses (one bit is reserved for read or write) but almost all devices have some of the remaining 7 bits fixed with only two or three bits available for you to use in an application. That might not be enough to select the LED drivers you need, especially if you need control over each color, meaning 1024 * 3 (= 3072) control signals.

The rating of an LED is normally for continuous operation rather than it's instantaneous peak current. The light output will be less proportional to current as you get nearer the absolute limit but the short pulse duration will help to reduce the heat dissipation which is one of the factors used to decide it's continuous rating. Your eyes are also non-linear in luminosity response so multiplexing 1:32 will not make the light appear to dim by 32 times.

Do you need to dim the LEDs or is it just color change needed in response to the phototransistor outputs? In other words is the color substituted in a particular area or is the proportion of colors adjusted to give different shades?

Brian.

I don't think there are any address limitations when using attiny88 as a I2C slave, I think any address between 3 and 127 is possible.

I do not require to drive each LED to maximum capacity, but let's say something like 80mA with a duty cycle of 1/32, would that reduce the life time of the LEDs by a lot?

I would like to be able to dim each led. The fototransistors are just one way the leds can be controlled, we are thinking of making them respond to sound among other things. I was thinking of having a 8-bit dimming resolution, but reducing it to a 4-bit resolution should be plenty I guess (that would only cut the information in half though).

Ok, so it isn't 'normal' I2C, you are copying the protocol but using your own addressing scheme.

Whether 80mA is overdriving the LED depends on the type of LED, some are designed to run at several Amps so you would have to look closely at the data sheet to find a practical limit. I have some commercially made gadgets here, manufactured by a 'reputable' company Phi**ips that pulse drive 3mm indicator LEDs at 80mA and most have had to be replaced after burning out with only a few hours of use!

The final design is up to you of course but the method I would look at is this:

5-bit counter to make an address bus.
address bus to 32-bit decoder to drive the common side of the LEDS.
3 * 32-bit data bus (4*8-bit perhaps) to drive the RGB side of the LEDs.
3 DACs fed with data according to the address bus and required brightness of each LED.
DAC controls the current source to each of the color groups.

that gives you individual brightness control of each color at each of the 1024 locations. Whether it is implemented in hardware or software is up to you but bear in mind that an ATtiny88 alone isn't going to be able to supply 80mA and you have to replicate the circuit 3,072 times to cover the whole table.

Brian.

You could use chains of WS2812 LEDs. One fast uC could drive multiple chains without the parallel overhead.
Might not be cheaper, but simpler.
- Wolfgang.

As far as I can make out from the WS2812 data sheet and the 'chains' advertised using it, each device drives all the LEDs in the chain. That implies that all the LEDs in the chain are controlled in parallel, they can be set to any RGB level combination but all the LEDs in the chain adopt the same brightness.

In this design, the LEDs need to be individually addressed so you would still need 1024 WS2812 ICs, one for each position on the table which would probably make it uneconomical.

Brian.