Propeller Display


I completed the first version of this project back in 2000. Based off of Bob Blick's propeller clock, it was a simple vertical column of 8 LEDs that spun in a circle, displaying a "Happy Birthday" message. A few years ago I stumbled across designs that had the LEDs on top of a spinning prop, instead of perpendicular. I wanted to design one! See the Youtube video of the project here.

Powering a Rotating Circuitboard

This is by far the most difficult obstacle in completing a project like can you deliver substantial current (32 LEDs @ 15 mA = 480 mA...almost 1/2 an amp) to a rotating circuitboard? A simple google search yields several methods. In this version, I opted for designing my own brush transfer mechanism. I borrowed some commutator parts from another electric motor, and placed a circular ring of copper on the PCB (see below). The ground connection was done through the motor's casing and spinning armature.


The display's LEDs are turned on and off at a sub-millisecond rate by an SiLab c8051F530 8 bit micro. Images can be stored on an on-board 1 M-bit EEPROM (25LC1024). The LEDs are driven using 4 driver chips, PCA9922. There are several options for integrated LED driver chips, and this one is fairly simple and easy to interface with. One of these chips can drive 8 LEDs, and they are loaded through a simple serial interface. Most of these kinds of LED driver chips allow for daisy-chaining; in my design I daisy chain 4 of them to get a total of 32 outputs.

A propeller display like this one relies on a phenomenon called Persistence of Vision, or POV. If the display is rotating fast enough (at least 25 rotations per second), the circuitry can turn on and off certain LEDs at certain times throughout the rotation to produce a static picture. Our brains trick us into thinking the image is actually static, when in reality it is not. See one of my propeller displays featured in a Smarter Every Day episode.



Timing is critical in order to know when to turn on a particular LED in the rotation. Two pieces of information are required: 1) How long does it take to make a single rotation, and 2) What is the position of the propeller at any particular time during the rotation. That first piece of information is pretty easy to compute. There is a hall-effect magnetic sensor mounted at the tip of the circuit board. This particular sensor digitally "closes" a switch whenever a strong enough magnetic field is passing through it. This field is provided through a small stationary magnet mounted on the frame of the display. The microcontroller measures the time between switch closures using an internal timer, and saves this value.

The second piece of information is a bit trickier. In my design, I update the row of LEDs 256 times per revolution. At this rate, the outermost LED travels about 1.4 degrees of a circle between updates. To automate the update process, and to reduce jitter as much as possible, the microcontroller divides that first value (the amount of time it takes for a single rotation) by 256, and repeatedly loads that 1/256th time into a counter. When that counter reaches 0, the microcontroller knows it's time to update the LEDs. We're essentially interpolating where the propeller is in a rotation, and so it's fairly independent of the speed of rotation.


The rotating cube is pretty awesome to see, but I'll confess here: there is no 3D engine that's computing the shape of the cube. It's simply 10 separate frames of a cube that I constructed offline. However, my RGB Propeller *does* have a built-in 3D engine.

At 25 frames per second, a single rotation takes about 1/25 seconds, or 40 milliseconds. Therefore, a row of LEDs is only "on" for about 40/256 = 156 microseconds. That's not much time to "look up" which LEDs should be on or off for the next row update! Luckily, there's enough internal RAM inside the microcontroller that can store an entire frame loaded from the (slooowww) EEPROM. A new frame gets loaded from the external EEPROM and into internal RAM. The microcontroller also has a lookup table stored internally that enables it to quickly determine which LEDs are mapped to which pixels within a frame's "bitmap". It then sends that data off to the PCA9922 chips and is subsequently latched for another 156 microseconds. Then, the update process begins again!

More Pics