Enigmaker

#project4 is...

Programmable Throwies

What do they do?

A tree or other arbitrary structure is augmented with many hundreds of LEDs, distributed randomly. At night, a lighting sequence can be programmed into the LEDs using a digital projector playing video or an animation directly onto the tree, which it then plays back faithfully.

The LEDs act as both input and output, and can each be independently monitored and controlled. The test pattern is recorded by using the LEDs as light sensors, compressed and recorded in memory. Each LED is then used as a light source, playing back the sequence of illumination it received on a loop.

In this way the trees are turned into a rich visual display. If you choose to use a solar engine, power from daylight can be stored in capacitors to power playback after dusk each day.

Demo

If you didn't see it - here's a demo of the test circuit

 

How does it work?

It relies on a little-used feature of the semiconductor behaviour of LEDs. It means that you can use an LED as a photodiode, (light sensor), and even alternate between using it this way, and using it as a light source.

Why is this design interesting?

Compared to other ways of building a controllable LED display, this approach has a number of advantages;

LEDs do not need to be positioned systematically

The position of each 'pixel' is not even known, yet they can act together as a coordinated display. Since the LED records the light incident directly on it, and plays it back in place, it doesn't need any complex model mapping a video sequence to individual pixels, and no communication system is required. This is very important if you want to deploy them by throwing them willy-nilly into the branches of trees.

The components used are very low cost

The 'analog' sensing can be done using digital ICs with no (expensive) analog capabilities. LEDs are ultra cheap, and the resistors can be left out altogether if running at a low enough voltage.

They are dynamically reprogrammable using very simple methods

Depending how they are deployed in the field, they could be programmed using mirrors, torches or car headlights, allowing people to interact with this display in compelling ways.

No central control

Each LED is a logically independent unit, needing only a timing pulse in common. Deploying them in clusters is mainly an issue of economics, to minimise the cost of ICs to control them. This radical decentralisation minimises the complexity of the system.

It's possible that the logic of Firefly syncrony could establish a timing pulse, as per the video below (via Boingboing) If it's possible to use a solar engine for power, and the timing pulse can be transmitted also through illumination, then no centralised wiring should be needed at all.

 

Redesigning the circuit

Makers who are following closely will see a mismatch between the demo and the partslist. In the demo I'm using the Atmega to directly read the LEDs as light sensors and control them as light outputs. That's because it's not clear what the most straightforward (and cost-effective) circuit design would be. The main issues are sequence memory, brightness and cost-per-LED. Here are some of the alternatives...

Use lots of PIC chips

By contrast with using a single microcontroller as the hub for a lot of LEDs as sensors and lights, this uses one microcontroller pin (one leg of a chip) per LED. It improves the available memory for the lighting sequences, with 2048 bits shared over maybe as few as 8 LEDs. It also means that in principle the LEDs can be illuminated most of the time, unlike the multiplexed alternative. Have to be careful with the power usage, though, if the LEDs are being driven directly.

Use fewer microcontrollers and multiplex the LEDs

Another extreme is to use lots of auxiliary chips to permit a large number of LEDs to be driven by a single microcontroller - a more complex circuit. It may end up hitting limitations in memory-per-LED which makes anything but the simplest pattern impossible to store without external memory (such as an SD card) which makes things even MORE complicated.

Somewhere in between

There may be a sweet spot with the use of Run Length Encoding, or a microcontroller-compatible compression algorithms to store the lighting sequences, the use of three-valued logic LED driver shift registers to control the LEDs (offloading power demands) whilst using Analog switches to monitor the LEDs in their light sensor phase (with the LED driver chips in High-impedance mode). I need to put together a prototype circuit and program to verify that this works and scales, and prove that chips with the correct features are cheap enough.

Related projects

The Graffiti Research Lab should be credited for the original LED Throwie concept. See also this and this for other projects using the phenomenon. See the Arduino playground article for simple example code using an LED as a light sensor. For contrast, also worth looking at Lancaster's Firefly Project which adopts the strong centralised control model.

Signoff

Thanks again for the guesses this week. Enigmaker isn't just about the guessing, part of the reason for this project is to unambiguously place inventions in the public domain where I and others can use them freely. As time goes on, I'd like to revisit each of these foreshortened projects in order to complete the designs and commercialise their distribution. Going paragliding again now, so a slightly early reveal.