I set out to create a large POV display for a local quarterly art installation called The Urban Art Project, in Great Falls, Montana. The space is 8 feet wide, 5′ 8″ tall, and around 17 inches deep. Two 1 meter rotors would nicely fit the space.
I wanted a project that would incorporate mechanical, electronic, and software elements, and eventually deliver a canvas to build artistic creations upon. The spinning POV display has caught my attention for years because of it’s apparent simplicity, yet it requires all of the disciplines listed. Based on what I’ve found with Google, there aren’t very many large format RGB displays. Challenge accepted!
- Must run continuously for 90 days. Ideally longer if I decide to sell the displays when the show is over.
- Must withstand temparatures of 100 F degrees.
- Must achieve a minimum of 5 frames per second.
- Must achieve an angular resolution of <LEDs across> * pi, or at least 188 divisions.
- Display PNG, JPG and animated GIF images.
- On-site software update via WiFi.
- LPD8806 LED strips with 60 LEDs per meter. LEDs the full length of the rotor. This seems like a no-brainer, but it reduces the needed RPM for good persistence by a factor of 2.
- WS8212 LED strips were used to prototype before I had the LPD strips. They proved to be too slow for this display, just as Adafruit’s product page advised.
- Raspberry Pi A+ with 3.3v -> 5v level shifter for SPI communication and WiFi dongle. Level shifter and power/led/sensor connections are mounted on an Adafruit perma-proto board.
- Hall effect sensor US5881LUA.
- Timing belt and pulleys to reduce A/C motor RPM and increase torque to rotor.
- 6 conductor (2 amps each) 12mm slip ring. 2 conductors for +5v, 2 conductors for ground, 2 conductors for SPI communcation. Rated to 250 RPM. I plan to overdrive this until it dies and watch for better alternatives.
- Carbon fiber arrow shafts for rotor arms.
- Machined aluminum rotor hub.
- Skateboard bearings.
3d Printed Parts
- Timing pulleys (http://www.thingiverse.com/thing:16627)
- Hall effect sensor mount
- LED strip mount to arrow shaft mounts
- Motor fans
- Bearing blocks for main rotor shaft.
CNC Machined Parts
- Rotor hub
- Motor mounts
A/C Motors Tested
- Random 9″ fan motor – I threw this one out. Similar to the 4M076D, but smaller. Way underpowered. 4:1 pulley ratio resulted in around 200 RPM at the rotor.
- Dayton 4M076D – 1/40 HP, 3000 RPM – underpowered, cooled with a desk fan, with 7.8:1 pulley ratio the rotor turned at ~250 RPM. Got almost too hot to touch, but not as bad as the smaller, similar motor. This was a bargain find at a local motor shop.
- Dayton 3M563B – 1/40 HP, 1550 RPM – plenty of power but no built-in fan, so it required additional cooling. This was a used motor that eventually died. I decided to not pursue this one because of the cooling requirement.
- Holmes 20″ box fan (Target) – Currently testing with a 6.5:1 pulley ratio. I added a 120mm fan to the front of the 30 tooth pinion. Rotor speed is ~320 RPM, and the motor is comfortably warm to the touch after over 1 hour. Next test will be to run overnight.
- Rotary encoder – Every motor exhibits a certain amount of jitter in it’s rotation speed. Using a single Hall effect sensor allows the software to determine the rotor’s position and speed once per revolution. So you occasionally see the display rotate a few degrees for a single frame, then recover. This effect looks cool and retro, but could be prevented. Using a rotary encoder would allow the software to correct speed variations many times per revolution. Combined with a Hall effect sensor, a very steady image could be created.
- Properly rated motors – Using inexpensive motors with homebrew cooling allowed this project to happen, but if money were no object, the clear choice is a TEFC (enclosed, fan cooled) motor of appropriate size. These start at around $100 each.
- More LEDs – Using LPD8806 LEDs, a C language frame buffer and SPI driver, twice as many LEDs could easily be driven. Especially on a faster Raspberry Pi. The current setup incorporates a 200us delay after each update to minimize CPU usage. Without this delay it achieves over 400 updates per rotation with 60 LEDs. An FPGA is a cool exercise, but is not strictly needed.