After being busy for almost one year with constructing my RGB LED coffee table it has finally happened: The almost complete table assembled in its full beauty! Wow! Pretty impressive to see everything together working for the first time. Okay, some hardware isn’t fully done yet, the software is in an early prototype stage and still some bugs have to be fixed until I’ll move to table from my shop to the living room. Nevertheless I’d like to share this moment and the current state of my project with you.
With the help of a good friend (thanks again, Jan!) I was able to assemble the table for the first time including all those electronic components I’ve worked on for the last months. Please apologize the rather poor quality of the pictures used in this post but I only did some pictures with my mobile and forget about using a real camera – probably I was a bit too exited in that particular moment 🙂 So for about ~30mins the table was fully assembled and running the current state of the software. Here’s a quick video taken with my mobile giving you a first impression of the RGB LED coffee table running one of the generators of the PixelController software called Plasma:
The RGB LED coffee table uses eight Rainbowduino micro controllers that each do control a 8×8 RGB LED array. Those controllers receive their data via an I2C link from a master micro controller. In the early days of the project I did use an Arduino UNO micro controller which turned out to suffer from a min. ~20ms delay while sending data via USB from the Mini-ITX PC via the I2C link to the eight Rainbowduino controllers. Since every to be updated Rainbowduino controller triggers another USB <-> Arduino UNO communication I did waste ~150ms for every to be updated frame with just waiting for the controller to pass through the data to the Rainbowduino controllers.
Since the author of the PixelController software did suffer from the same problems he did some measurements of the serial latency issue of different micro controllers of the Arduino universe. The Teensy USB Development Board has proven to be a practical alternative for the official Arduino micro controllers since the manufacturer also offers an Arduino Software extension called Teensyduino that allows you the run more or less the same sketch on the Teensy controllers using the same software used to program the official Arduino controllers. After replacing the Arduino UNO controller with a Teensy 2.0 controller I was able to increase the throughput dramatically but still not as fast as I’d like to. After several performance and threading related improvements of the PixelController software I was able to almost archive ~18 fps with a single Teensy controller driving eight Rainbowduino controllers – not bad but still not as fast as I’d like to update the LED arrays.
The current state of the coffee table shown in the pictures does use two Teensy 2.0 controllers each driving four of the 8×8 LED arrays. This allows me to easily archive 25 fps as desired. It also allows me to update at least two of the Rainbowduino controllers in parallel so that the tearing effect was also reduced noticeable with splitting up the Rainbowduino controllers. Still there are some things that I don’t consider as ideal:
- Updating the Rainbowduino micro controllers with more than ~20 fps leads to some timing related drawing errors that result in some of the updated LED rows to appear brighter than the other rows on the same 8×8 LED array. So from time to time you get the impression that a single row of an 8×8 LED array does flash up for a short moment.
- The resolution of a Rainbowduino controller is limited to 12bit. 12bit for each RGB LED means 4bit resolution per color channel which means the controller can only render 16 different red, green and blue color shades per LED. Especially if you don’t want to use the full brightness of the LEDs you’ll quickly notice some not so smooth color transitions.
- Some of my controllers do suffer from another timing related problem that results in still slightly illuminated rows although all LEDs should be disabled. In the meanwhile this bug is already listed in the Rainbowduino documentation but I wasn’t able to pin this one down yet. For one of my affected controllers it turned out that this bug was temperature-dependent, for another controller I was able to fix this with replace the non lighted up LED of an affected row. But still there seems to be no pattern to handle those problems in a reliable way.
- It’s kind of painful to bring all Rainbowduinos to the same brightness level since there’s only one potentiometer on each controller allowing you to regulate the current send to the LEDs. I wasn’t able to measure that potentiometer value in a reliable way to get all controllers to the same current level. Also I have the feeling that the controllers are a bit temperature-sensitive depending on the pattern the controller currently sends to the LEDs and their resulting power consumption.
Since those problems will be very hard to fix or are even limited by the hardware used to drive the LEDs I’ve decided to give the new Rainbowduino V3 controllers a chance. My hope is that due to the native USB interface I don’t need to use an Arduino UNO or a Teensy controller to send the data out via an I2C link and rather connect all the controllers directly via USB to my Mini-ITX PC. I expect those new controllers will have the same ~20ms serial latency as the other Arduino controllers since they do use similar hardware for the USB part. Nevertheless I think that this won’t be an major issue since I will be able to update all eight controllers at roughly the same time via their USB interface (if I do ignore the serial architecture of the USB bus for a second) so that those ~20ms don’t pile up while sending a full frame to the controllers. Furthermore the Rainbowduino V3 controllers do use a different LED driver IC that provides a higher color resolution. I’ll keep you informed with another blog post how those controllers worked out for my coffee table project.
Despite all the pointed out problems or possible improvements I’m still very happy with the current state of the project. The smoked glass matches the American Walnut boards in a good looking way in my opinion. Also the satinized foil attached underneath the smoked glass works quite well and gives you the impression that you actually look at a 4x4cm illuminated square rather than actually a single RGB LED sitting on the bottom of the Polystyrene grid. I was a bit afraid of possible color distortions coming from the smoked glass but this initial assembly test did still my fears. Also the overall brightness level is more than sufficient and the ‘cross-talk’ between each LED pixel through the not 100% optically opaque Polystyrene gird and the reflections of the glass is visible but not disturbing in my view. Overall I’m more than pleased with the current state and will continue to get the remaining outstanding tasks done so that I can finally move my table over to my living room.