As part of my school’s electronics hacking/tinkering session called Build18, I’ll finally be spinning the RGB sticks I designed over two years ago. Starting this week on Sunday Jan. 15, groups will only have 5 days to complete their project. This “annual engineering festival” is a great way for ECE students of all years to participate in designing a practical embedded system with help from their peers.

This is the inspiration for the project:

I believe this is one of the best ones out there right now. But note that only 8 colors are possible — each R, G, B pixel can only be off or totally on. My RGB sticks use the TLC5947 to achieve 12-bit resolution per color, for 4096 viewable levels. However, this greatly complicates the controller. The refresh rate must be very high since the LED’s are in rapid motion, but adding resolution will greatly slow down the update rate.

Power will be transmitted through the spinning motor to the RGB sticks. I’m going to try to spin as many of the chained sticks as possible, each one adding 8″ to the diameter of the propeller clock. I have no idea if the mechanics of this will work, or even if modifying the motor to transmit power will work. I don’t think we’ll get DC power out of the motor due to the three brushes alternating contacts, but I could be entirely wrong. If all else fails, I’ll just bruteforce it and just spin 4x AA batteries and live with the few hour battery life

To communicate with the microcontroller on the spinning device, a pair of nRF2401A transceivers will be used. In ground frame, there will be an additional microcontroller hooked up to sensors and controlled by a laptop which will send high-level command signals to the spinning device.

For maximum refresh speed and awesomeness, we’ll try using the extreme overkill XMOS XC-1A dev board, which has a XS1-G4 micro, capable of operating at 1600 MIPS with high parallelism, perfect for generating data to send to shift registers really fast. If this ends up being too complicated, the fallback plan is to use an mbed, which has an ARM Cortex-M3 running at a measly 96 MIPS. Each RGB stick has 32x RGB LED’s, and the shift registers are 12-bits, so there’s 1152 bits to update per stick per refresh. Displaying an intensity correctly involves doing some math to perform gamma curve correction, or resorting to using a 4096×12 bit lookup table per pixel, which can be slow.

I’ll be posting progress updates throughout the week. Day 1: mbed Benchmarking