Programmers' Pain
9Sep/133

No, I haven’t burned my 512 RGB LED coffee table (yet)..

The assembled coffee table doing it's main job in my living room: being a table :)

The assembled coffee table doing it’s main job in my living room: being a table 🙂

No, I’m still alive and no, haven’t turned my coffee table into a big camp fire (yet) 🙂 I was just busy with renovating my flat and some other projects that I’ll show you in some future blog posts as well. Therefore I didn’t had too much spare time left that I could invest into my 512 RGB LED coffee table project lately. Still I want to give you a brief update what has happened in the meanwhile: I closed my last blog post with basically having the table hardware-complete but still not finally assembled to be able to fix any hardware related bugs that might show up while continue testing it. For some weeks I’ve left the table in that state, did test various things and fixed some bugs before I put it together and moved it over to my living room where it just does it’s job as a good looking coffee table. Since I can’t use my notebook to connect to the Rainbowduino V3 controllers any more I had to spend some time on getting my Java software easily deployable to the tables PC and to add a hook into the Linux installation so that it starts up while the PC is booting. Feel free continue reading if you’re interested in the details on how I did that and to get some additional insight in the current state of the tables Java software.

Table with an attached side panel while applying the last finishing touches to the LED panels

Table with an attached side panel while applying the last finishing touches to the LED panels

Let’s say that Fedora 17 and the introduction of the new systemd system that replaced the old init / SysVinit way of starting up a Linux distribution and its services wasn’t a pleasant experience for me – I think I still haven’t fully understood it so far. At least it took me a while until I’ve managed to start my software running as a different; non-root user after the various USB devices of the different Arduino / Rainbowduino controllers and the syslog service has been initialized. I also had some trouble with the latest kernel versions that were released for Fedora 17 since they led to I/O hangs while sending RGB frames via USB to the Rainbowduino controllers. It took me a while to track this down to the patched version of the RXTX library that I use to send data to the serial ports of the controllers. Also this hanging bug only showed up if sending data to four or more Rainbowduino V3 controllers at the same time. The version of the RXTX library bundled by the Linux Arduino distribution doesn’t show this error but contains some additional latency while sending data to the controllers that I don’t want to have. For that reason I plan to play around a bit with the patched changes in the near future to see if I can somehow find a compromise between stable serial connections and not to much lost performance.

Table with all side panels attached surrounding the polystyrene grid

Table with all side panels attached surrounding the polystyrene grid

Also the Java part of the tables software has been grown up a bit from a kind-of prototypic application directly launched from Eclipse to a client – server architecture exchanging the LEDs color data as well as all control messages via an ActiveMQ Apollo broker. I choose this communication framework since it’s based on the STOMP protocol which gives you a human readable message format that simplifies debuging those messages used for transferring data or remote calling Java functionalities in my use case. On the other had the messages are not that small and performant as compared to other messaging frameworks but since I’m not running a performance critical application here I rather enjoy readable messages than getting the maximum performance out of it. Anyway, the default configuration of ActiveMQ Apollo running as an embedded broker in the server part of the tables Java software is more than capable to receive and handle all incoming control messages like switching the currently running animation or input data from external controllers etc. in a reasonable amount of time without producing a noticeable latency. Whenever the main animation thread of the servers Java code is busy producing the next to be shown frame the broker has more than enough time to handle all incoming messages and providing the resulting state changes to the animation thread to be used for the next produced frame.

Close-up of the polystyrene grid surrounded by the tables side panels

Close-up of the polystyrene grid surrounded by the tables side panels

Also do I use the embedded ActiveMQ broker to send out the raw data of every produced frame to connected clients of the tables server software. Right now I use this data to show the produced frames in a small JavaFX debugging application that allows me to see the frames produced by the table on my PC while developing the servers software. Also I’m able to run the server part in a sandbox mode allowing me together with the JavaFX debugging application to develop the software without even turning on the coffee table itself. For the near future I also have some plans to create an Android-based frontend that can be used to control the table and display the frames being produced by the server software simultaneously. Since the STOMP message protocol used by my ActiveMQ Apollo configuration can be easily parsed in Java even on Android devices an application connecting to the tables server doesn’t need a huge set libraries just to be able to parse text-based messages. Therefore most of the available client libraries for the STOMP protocol have a very small footprint and mostly don’t depend on any external libraries at all.

The lower part of the table containing the speaker housings with removed covers

The lower part of the table containing the speaker housings with removed covers

Lately I’ve also reinstalled the tables PC with Fedora 19 running the minimum software configuration without even having an X11 server installed as I did before with the older installation to be able to run an older version of the tables software directly from Eclipse on that PC. So to be able to get the server part to the tables PC I had to write a quick’n’dirty deploy solution that will be executed on the same PC I do use to develop the software. To do so the client- as well as the server-part of the software gets build using the Gradle build system. The tables software consists out of three different projects that are used to split up the code into client- and server only classes as well as into a shared project containing classes and resources that will be used by both. The shared code consists mostly out of the messages being exchanged as well as global configuration data. A fourth Gradle project is used to bundle the code of the server- and the shared-projects as well as their transitive dependencies into a single JAR file. After that a simple Bash script gets called that transfers the JAR file, a JRE and the necessary configuration files to the tables PC. After that the service controlling the tables server software gets restarted via systemd.

One of the two compartments that isn't occupied by the tables electronics

One of the two compartments that isn’t occupied by the tables electronics

So what’s my plans for the next weeks and months in regard to my 512 RGB LED coffee table project? First I want to finish a new version of my rainbowduino-v3-streaming-firmware that’ll fix some of the problems that I’ve found since the last release. It’s mainly about fixing some issues with the Arduino IDE 1.0.x update (yeah, I know it’s available for quite some time now) and adding support for an idle animation / screen that gets shown if no frames are received. This should help new users of the firmware to quickly check if the firmware after flashing a Rainbowduino V3 controller does work properly. It’s also a helpful feature to easily check the LED matrix orientation. Furthermore I’m thinking about introducing a “switch frame”-message to the firmware and the Java API which gets send after every Rainbowduino V3 controller did receive a new frame. Background is that with eight Rainbowduinos running at 30 fps you sometimes notice smaller tearing effects if e.g. half of the controllers show the new and the others still show the previous frame (this also depends on your LED matrix / panel orientation). I’ve noticed that starting with four or more controllers connected to a single USB hub the shared USB link to your mainboard leads to those tearing effects since the messages have to be send one by one over the shared USB link although every controller has it’s dedicated (virtual) COM port as well a an dedicated internal thread in the Java API that feeds each COM port simultaneously with the others. I want to play around a bit with such a “switch frame”-command to see if this makes a difference and hopefully doesn’t slow down the overall performance noticeably.

Murphy's law at it's best: Assembing the table without checking the LED panel connections to the Rainbowduino V3 controllers: Another half hour wasted for tearing everything down again

Murphy’s law at it’s best: Assembing the table without checking the LED panel connections to the Rainbowduino V3 controllers: Another half hour wasted for tearing everything down again

After that I do want to focus a bit more on the Java code and add the necessary interfaces to the front panels of the table so that I can start using all those fancy buttons to control the table as well. Also I want to clean up my codebase a bit and remove all those testing bits and pieces and continue working on writing some animations I’d like to see on my table – including a different way of cycling through the different animations. As already hinted above I also have some plans & ideas for a Android-based frontend for the table that can be used to change the running animations and to control all those global options like brightness, color balance and the different settings of each animation if available – but I have the feeling it’ll take a while until I’ll get to that point… But, whenever something interesting happens relating to my coffee table project I’ll keep this blog updated 🙂

Comments (3) Trackbacks (0)
  1. Glad to see you got round to posting an update Markus 🙂

    Interesting read (over my head in parts if I’m honest).

    Keep it up!

  2. Where did you get the plastic grid and the LED arrays? Both are very very nice.


Leave a comment

Connect with Facebook

No trackbacks yet.