What can 2 ECE’s, a MechE and a CS major do in only 5 days of hacking? This is a project done for CMU’s hack-a-thon session called Build18. The LED boards were previously designed by me but all other work was done in the week-long session.
96 RGB LED’s driven by 12x TLC5947 LED drivers. 12-bit PWM resolution per color channel per LED.
Diameter: 1.5 feet
Full brightness: 6 amps of LED current
Didn’t have time to figure out how to transfer through motor, so it is battery powered by 2x 4AA NIMH cells which have the perfect discharge curve for what the LED drivers need.
Don’t forget the obligatory Jimmy Wales face:
Flickering is due to interaction between camera frame rate and update rate of the propeller clock and is not that bad in real life. Thanks to all my group members who have done the majority of the work!
Costas Akrivoulis – Junior ECE, Coding, mounting, lots of stuff
Jitu Das – Junior CS, algorithms for display and pre-processing of images
John Howland – Senior MechE, designed the mount and all mechanical parts — the hardest part for us ECE majors
Allan Wang – Senior ECE, Designed LED boards, hardware
Much more technical details will be posted shortly after the dust settles from demo day.
I’ll first start off with some speed tests to see the maximum refresh rate achievable with the mbed, which has a 96 MHz ARM Cortex-M3 processor.
Interfacing the MCU to the TLC5947′s is interesting because the TLC5947′s run off 5V, but the MCU runs off 3.3V. The TLC5947 datasheet also states the maximum clock is 15 MHz when cascaded. I tested with 2 cascaded sticks (8x TLC5947), and found I can clock SPI to 24 MHz (maximum speed supported by the MCU)! With 3 cascaded sticks, only 16 MHz works. This is still pretty amazing because the MCU output is driving a large capacitive load with voltage logic levels mismatched. From looking at the scope captures, the difference in logic high amplitude between 16 MHz vs 24 MHz is very small, yet one fails and the other works. Even dialing down the TLC5947 voltage doesn’t fix anything until they’re brought to around 3.6V. All of this isn’t a huge deal, because SPI communication is at most 5% of the total time spent in each cycle.
The test is to cycle through all the hue’s for each LED, displaying a rainbow across the stick. Therefore a conversion must be done from HSV space to RGB space. Then to display each pixel, a gamma correction calculation must be performed for each color, since the human senses are logarithmic. This involves doing an exponential and a few floating point operations. How fast can the ARM perform these operations?
There are 3 sticks cascaded, for a total of 96 RGB LED’s — 288 pixels with 12-bit resolution. My optimized code refreshes at 256 Hz, which is great for a stationary display, but probably a bit on the low side for a rapidly moving one, like using it for a propeller clock. I noticed a few tricks that improved performance by about 20% total:
Explicitly cast all constant floating point numbers into floats. Otherwise the C compiler will default them to doubles and the ARM will perform double calculations, which is slower.
Turn division of floating point numbers into multiplication.
When possible, use integers as an operand for floating point math. For example, if hue is a float, hue / 60 is actually faster than hue * 0.0166667.
I’m sure removing the floating point code entirely will greatly speed up the refresh rate, but this is harder to develop. Another thing to try is to use a lookup table to save the use of the exp() function and a floating point multiply. Just tried the LUT and got 600 Hz — pretty good improvement.
Then I converted the HSV to RGB code into pure integer math. This got it to 1590 Hz! Maybe the XMOS won’t be needed after all.
Tomorrow we’ll give the XMOS dev board a try, which has 1600 MIPS — almost 16x the speed of the mbed.
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.
Recent Comments