A snapshot taken of the main technical compartment somewhere in the midle of getting some wiring work done

Eight months.. wow! Quite some time has passed since I've decided to switch my more or less working 512 RGB LED coffee table to the newer Rainbowduino V3 controllers to drive those LEDs. At this point I couldn't really anticipate that getting a working firmware for my needs up and running would be that time consuming. Luckily I was able to solve this problem nearly two month ago so that it was time again to focus on the table and get the remaining hardware tasks sorted out. If you want to find out what has happened the last two months concerning my coffee table project than feel free to continue reading this blog post

Getting back to work on the table hardware itself wasn't really fun in the beginning since I had to remove quite some internals first that I've added to get my old Rainbowduino V2 controllers flying those days. That included two Teensy controllers that were used to drive four Rainbowduino V2 controllers each and all the wiring effort needed like the I2C links between them or the power supply of the controllers - cutting this stuff off with a wire cutter destroyed quite some hours of invested working hours. The god thing is that the whole wiring effort for the new Rainbowduino V3 controllers has been reduced to a simple USB cable plus an additional wire to be able to reset them. That's quite an improvement compared to those RX/TX, I2C, reset and power supply cables needed by the old controllers.

The two front panels as they have been delivered to me by the Schaeffer AG

After those leftovers were removed I continued working on the front panels that I will use to cover my two technical compartments containing the PC and the amplifiers. The easiest and probably also the cheapest way to archive that would have been to get some plywood and drill the necessary cuttings into it manually so that you wouldn't be able to touch the dangerous parts of the table internals and potentially get electrocuted any more. After drawing the first sketches I've noticed that I have quite some buttons and knobs that I want to expose to the outside. While thinking about the effort needed to drill all those holes and cuttings by myself - which includes a high chance that it'll look like crap after I'm done with it - I thought it's maybe an better idea to go for some milled aluminium front panels instead. With the Schaeffer AG located in Berlin, Germany I've found a nice company that did helped me out. They're focused on milling individual units or small production runs and do offer a simple to use design program that is also able to show you the expected manufacturing costs while designing your front panels. I've ordered two panels for a reasonable price which saved me quite some work compared to if I would have tried to make those front panels myself. The quality of those panels was flawless and I can only recommend this company.

Some snapshots taken while milling and assembling the shielded casing for my subwoofer crossover

After the front panels have arrived I've started with the panel covering the amplifiers and the subwoofer crossover. As mentioned in one of my older blog post I did cut my Reckhorn S-1 active subwoofer crossover into two prices a while ago to be able to mount those knobs directly behind the front panel. Since those potentiometers are potentially prone to disturbing noises I wanted to cover then in a metal shielding casing which I originally planed to manufacture it myself out of ordinary sheet metal. Fortunately did my co-worker Boris offered me to help me out with his milling machine so that this saved me quite some time as if I would have to build this enclosure myself - thanks again, bud!

Some different views of the front panel of the technical compartment containing all sound related hardware

So after adding the enclosure containing the subwoofer crossover and the control elements of my two Thomann THE T.AMP S-100 2x100W Stereo 19″ PA amplifiers I was able to mount the front panel inside the technical compartment that contains all sound related hardware. To make it look a bit nicer and to actually be able to see something when you open the door of this compartment I've mounted some white LEDs in the ceiling that do dim up as soon as you open the door. Those LEDs are controlled by a reed switch per compartment door that do trigger some PWM outputs of my Arduino Mega 2560 controller which are used to drive those LEDs. To not overload those outputs a transistor is used to limit the power consumption the controller has to handle.

Some different views of the PCs front panel that provides several push buttons to be able to interact with the 512 RGB LED coffee table

The second front panel required a bit more work to get it done since it mainly contains a bunch of push buttons to be able to interact with the coffee table. Therefore I've added some basic menu-like navigation buttons, three pairs of buttons to switch the currently shown visual, the used color palette as well as the brightness of the LEDs followed by five buttons and a matching LED per button that can be used for some sort of custom or context driven functions that I don't know about yet. Beside those buttons used to interact with the table also a bunch of technical things have been added like being able to control my FS20 sender and receiver modules as well as some buttons used to reset the different micro-controllers inside the table in case something goes wrong. The five big push buttons in the middle of the PC compartments front panel are used to trigger the main power of the table and to power on / reset the build-in PC. Also the two FS20 main power switches can be controlled using those buttons. The ATX I/O shield is exposed here too in case I want to interact with the build-in PC. However the most important part of the front panel is still the green main power switch that shuts everything down including the standby power supply of the table which is used to drive those micro-controllers that are able to power up the rest of the table.

Getting the PC front panel done was a bit more labour-intensive since I had to do all the wiring work need to connect those buttons and LEDs to the same Mega 2560 controller that drives the compartment lightings I did spoke earlier about. Also getting this beast mounted was a bit trickier since there isn't much space left to get all those wires to the right place - and a mounted PC including its power supply in the same compartment doesn't really make it simpler.

The current state of the main technical compartment after all major wiring work has been done

After both front panels have been put in their spot I was busy with finalizing the wiring inside the main technical compartment of my LED coffee table. The main things needed to get done there were the USB cables for the Rainbowduino controllers and modding a 10-port USB hub to be able to connect them to the PC. Mainly I had to change the power supply of that hub since I didn't want to put another 5V power supply into the table. Also the bundled power supply of the hub was only able to provide ~3A which could be a bit too less if each of the eight Rainbowduino V3 controllers can consume up to ~450mA depending if all LEDs are active or not. Therefore I've just connected the hub to the 5V line of the PCs power supply which is able to provide enough power to drive those Rainbowduino controllers.

So right now I'm basically done with the hardware I wanted to put into my 512 RGB LED coffee table. It's still not completely put together and actually used as a table yet since I want to get the software of the table into a state where I can test all those front panel buttons first before finally putting everything together. In the current state everything is still easily accessible so that fixing potential problems will be way easier than having the table already standing around in my living room. Still I'm very excited to put everything together but so far I've managed to hold myself off to not rush the final assembly at that point - but I have a very good feeling that it won't last too long until I can put this beast finally together

RAID1 setup using Linux software raid and LUKS encryption

After one of my last blog posts dealt with modifying my two Sharkoon SATA Quickport XT USB3.0 docking stations I did spend some time figuring out how I can use them to set up multiple RAID1 volumes that should be encrypted using the LUKS environment of recent Linux distributions. Also I was searching for a mechanism to clearly map every involved disk to an unique raid volume so that I don't end up with a generic mount point like /mnt/raid1/ that would just show the content of the currently docked disks - instead every RAID1 volume should have it's own dedicated mount point. The solution I've came up with uses UDEV rules to identify the disks, mdadm to map two disks to a single software-RAID1 volume, cryptsetup to encrypt the raid volume and some smaller, self-written helper scripts that do simplify the usage of those external RAID1 volumes. How it all works and how you can set up such an environment on your own Linux machine: just click 'continue reading'

Defining UDEV rules to get unique symbolic links for each disk

So the general idea is that each disk will have a dedicated UDEV rule which will result in a unique symlink in the /dev directory pointing to the actual block device the disk has been made available at by the Linux kernel. In addition to the /dev/sdd and /dev/sde mount points where my docking stations usually do show up each docked disk will have an unique symlink like /dev/raid1v1d1 and /dev/raid1v1d2 pointing to the actual /dev/sdd and /dev/sde block devices. raid1v1d1 stands for: raid1, volume1, disk1 in this example to give those symlinks a meaningful name without being forced to type tons of text. With using those symlinks I can set up multiple RAID1 volumes with mdadm that won't collide with each other as if you would have used the /dev/sdX block devices directly since the real block devices will be shared by multiple disks:

Imagine you'd have set up two RAID1 volumes with mdadm that would directly use the /dev/sdX block devices - If you would put one disk of each RAID1 volume into the docking stations than the second disk you've inserted would be detected as an out-of-sync disk of the first disks RAID1 volume since both RAID1 volumes do share the same /dev/sdX block devices. The result would be that the RADI1 volume of the first docked disk will run with only one active member disk and the second disk would be handled as an out-of-sync disk although it isn't even a member of the first disks RAID1 volume. Even worse: if you would trigger a resync of the RAID1 volume than you'd delete the contents of the second disk if you'd skip the 'this disk contains metadata of another raid volume' warning message! To eliminate that risk in general I'll only use those unique symlinks defined by the following example UDEV rules:

Those example UDEV rules that I do store in the /etc/udev/rules.d/99-usbRaid1.rules file on my Linux machine are doing multiple things:

• define raid1v#d# symlinks for in total four different disks that are identified via their serial numbers (ID_SERIAL_SHORT property).
• define raid1v#d#p1 symlinks for the first partition for each of the four disks.
• those rules will only be considered if the the new /dev/sdX block device is provided by the USB subsystem of the kernel since I'm using USB3.0 docking stations.

So whenever I dock one of those disks two additional symlinks (/dev/raid1v#d# and /dev/raid1v#d#p1) will be created if the new block device was provided by the USB subsystem and if the serial of the disk matches the one defined in the UDEV rules. You can use hdparm the get the serial number of a disk via its block device:

Whenever you change existing UDEV rules or add new ones than you should restart the UDEV service of your Linux distribution and call udevadm to force UDEV to re-trigger all known UDEV rules for all existing block devices. As an alternative you could also re-connect your USB disks so that UDEV will consider your new rules as soon as the disk are available again.

If you haven't set up your disks with a fresh partition table and an empty first partition yet I'd suggest to use parted, gparted or any other disk partition tool to do so. For all of my disks I did use a GPT partition table and a primary partition without any file system type since it will be used by mdadm own data format anyway. After you're done with setting up the partitions and calling udevadm trigger once again you should find the following entries in your /dev directory assuming that you would have the disks with the exemplary 1234511111 and 1234522222 serial numbers up and running:

Setting up RAID1 volumes using mdadm

So whenever you're done with setting up the partitions you're ready to call mdadm to create a new RAID1 volume using the two partitions of the two disks available via the symlinks defined by the UDEV rules:

What has happened here is that we've just created a new RAID1 volume that will be available via the /dev/md/raid1v1 block device following the same naming schema as the disk symlinks. As soon as the mdadm call returns to your Bash console prompt the new RAID1 volume is ready to be used. If you want to have a quick look at the current status of the new volume just have a look at the /proc filesystem:

The output of /proc/mdstat contains several interesting information that are worth to talk about in a bit more detail: The first thing you should notice is that your new /dev/md/raid1v1 block device is again just an alias for the real /dev/md127 block device provided by the Linux kernel. Again, we're following the same principal as we did with the disks that each RAID1 volume will have an unique symlink so that we can mount it in a dedicated location. As for the disks it's again uncritical that we reuse the real block devices like /dev/sdd, /dev/sde or /dev/md127 since we can only mount two disks at the same time.

The second thing is that although we explicitly specified the symlinks we've set up with our UDEV rules the Linux software raid implementation still uses the real block devices the disks were made available by the Linux kernel. This is again not a problem since we only use those symlinks to have an unique device name per disk and raid volume. This symlink-based approach will especially show its benefits if you would get another couple of docking stations to be able to have two RAID1 volumes running at the same time or if you're thinking about mounting two disks directly into your PC: In both cases you'll just don't care which block devices the kernel will choose to give you access to your disks since you'll only use those symlinks to access your RAID1 volumes. Also mdadm will use the same approach to give access to those volumes via /dev/md127, /dev/md126 and so forth but all you'll care about are those /dev/md/raid1v# symlinks:

Also notice that mdadm will automatically provide you with additional symlinks for every partition on your raid volume. So whenever you've used gparted or a similar tool to create an empty partition on the /dev/md/raid1v1 block device you should see the same content as above in your /dev/md directory.

Encrypting the RAID1 volume using LUKS / cryptsetup

As written in the introduction of this post I also want to encrypt those RAID1 volumes using LUKS environment and its cryptsetup tool. Setting up an encrypted container isn't really complicated if you're happy with using the default values:

I've added the --verify-passphrase argument on purpose since otherwise cryptsetup would just create the encrypted container without validating the password you've entered via the passphrase prompt. To be able to use your just created cryptsetup container on top of the mdadm RAID1 volume you have to open it first so that it's unencrypted content will be available via another block device to be found in the /dev/mapper directory afterwards:

After you've opened the encrypted container using the password you've used while setting up the container you'll find a new block device called /dev/mapper/luks-raid1v1 that you can format as any other disk partition with your favoured file system.

If you've followed the instructions of this blog post so far you should have a formatted block device by now that is ready to be mounted and used. Since triggering a single umount call isn't enough to stop the LUKS block device and the RAID1 volume behind it you'd need to issue the following commands to stop your encrypted RAID1 volume again:

The next time you want to use your RAID1 volume again you would have to trigger similar commands in a reversed order:

1. mdadm to start the RAID1 volume again
2. cryptsetup luksOpen to provide a decrypted block device in the /dev/mapper directory
3. mount to make the RAID1 volume accessible

Since that's kind of boring commands to type every time you want to use one of your RAID1 volumes and since there's a chance to mess things up if you e.g. forget to stop the RAID1 volume before ejecting the disks from the docking stations I did create two simple helper scripts that can be used to automate those calls.

Helper scripts to simplify (un)mounting the encrypted RAID1 volumes

To be able to automated the (un)mounting process of your RAID1 volumes it makes sense to define a common base directory where each volume will be mounted using a dedicated subdirectory. I did choose the /mnt/usbRaid1 directory for that purpose. So beside initially creating this base directory you would have to create a new subdirectory for every newly created RAID1 volume:

After creating the raid1v1 subdirectory inside the /mnt/usbRaid1 directory you're ready to mount the RAID1 volume from this example. Before mounting it for the first time I've also created an empty "not mounted!" file and set its permissions to read-only so that you can instantly see if the RAID1 volume is mounted or not.

After mounting your RAID1 volume the "not mounted!" file isn't visible any more since the /mnt/usbRaid1/raid1v1 directory now points to your encrypted RAID1 volume. At that point it's pretty easy to simplify the (un)mounting process since we did use a consistent naming schema for all device, symlink and mount point names so that providing the volume name (raid1v1 in this example) to a Bash script is enough to trigger all actions inside the script. For that purpose I've created two Bash scripts called raid_open.sh <volume name> and raid_close.sh <volume name> that take care of opening a RAID1 volume and mounting it into the matching directory and closing the volume again:

So opening the raid1v1 encrypted RAID1 volume from this example is as simple as calling raid_open.sh raid1v1 which will internally call cryptsetup that will ask you for the password of the encrypted container. Closing an currently mounted RAID1 volume is also straight forward via calling raid_close.sh raid1v1. Both scripts provide an basic error handling and do print some additional information in case something goes wrong. Please not that the raid_open.sh script does use the example /mnt/usbRaid1 directory used to mount the RAID1 volumes into their matching subdirectories. If you want to use a different directory you need to change the script accordingly.

I do use my external RAID1 volumes in the described setup for quite a while now and I'm pretty happy with the usability of that solution. As usual there's still ways to further improve this like e.g. using the automount daemon to trigger those scripts automatically combined with some sort of shared token for every RAID1 volume that you only have to authenticate once at e.g. the system startup so that you don't have to type the LUKS containers password every time you want to mount a RAID1 volume. But compared to the usual mount and umount commands you'd trigger for normal disks the two scripts aren't really a major drawback. Anyway, I just wanted to share my solution - maybe it's considered being useful by some other Linux users out there

Two Rainbowduino V3 controllers running the 'rainbowduino-v3-streaming-firmware'

It took a while but I've finally managed to get the firmware of my new Rainbowduino V3 controllers to a state that I can use them as part of my 512 RGB LED coffee table project. I've learnt a lot of new things about interrupt handling of AVR micro controllers that I didn't want to learn at all and I went trough quite some frustrating weeks where I was very close to just throw those controllers into the trash. But luckily I've managed to get the firmware flying at the end. If you want to find out what obstacles I had to fight with, how it all works at the end and where you can find the Rainbowduino V3 firmware including the matching Java API than feel free to continue reading this blog post

The first firmware I've tried for my new Rainbowduino V3 controllers was the reference firmware offered by the manufacturer (seeedstudio.com) of the controller. The firmware works quite nice but it targets for standalone usage of the controller without any functionality to stream 8x8 RGB frames to the controller via an I2C link or the build-in USB connector. Since I've already used the neorainbowduino firmware for my Rainbowduino V2 controllers that were used for the first test assembly of my coffee table I was also familiar with sending those frames with the help of an Arduino Uno or Teensy controller via an I2C-link to the Rainbowduino controllers. Sadly the neorainbowduino firmware can't be used for V3 controllers since seeedstudio.com has change the controllers hardware quite a lot. Also I did know from my initial tests that the I2C-link approach is limited to max. four Rainbowduino controllers per Teensy controller since otherwise those controllers will act as the bottleneck preventing the Java program from sending RGB frames at ~20fps. An Arduino Uno due to his even worse serial performance isn't able to drive more than two Rainbowduino controllers at ~20fps. Therefore it was quite obvious for me to focus on the build-in USB connector of the Rainbowduino V3 controller since this would solve several problems for my use case:

The eight Rainbowduino V3 controller of my 512 RGB LED coffee table project

• Direct serial connection to every Rainbowduino V3 controller without having another controller like an Arduino Uno or Teensy in-line that will act as a bottleneck.
• No need for an external power supply since each controller can be powered directly via the USB connection.
• No additional wiring needed for the I2C-links or being able to upload the controllers firmware since both can be done via a single USB cable.

Actually there's one drawback of using an USB connection compared to to an I2C-link: You won't be able to directly daisy-chain those controllers any more since the USB plug will be in the way. Luckily this isn't a problem for my project since I do use some self-build 34x34cm LED panels so that I have enough space for an USB plug attached to each of my controllers.

While searching a bit for Rainbowduino V3 firmwares that claim to be able to send RGB frames via an USB connection I only found the rainbowdash firmware which offers an operation mode called DirectMode that is able to send RGB frames via serial to the controllers. Sadly this only works up to a baudrate of 19200 until the firmware suffers from data corruption / data loss due to conflicting interrupts: the internal Arduino interrupt that is used to receive incoming serial data and the interrupt of the rewritten seeedstudio.com firmware used to drive the LEDs. Conclusion: I own eight new controllers but there wasn't any firmware available to stream 24bit RGB frames with 8 bit per color channel to those Rainbowduino V3 controllers via the build-in USB connector. Therefore I've decided to start my own firmware trying to combine the features of the neorainbowduino and the original seeedstudio.com firmware. That was end of March - or in other words - five month ago.. I had no fucking clue in what kind of trouble I'll put myself into..

So.. It's mid-September in the meanwhile, I've learned things I didn't want to learn, I've fought with issues I couldn't imagine five month ago and I was quite frustrated sometimes.. but I've managed to get my Rainbowduino V3 firmware including the matching Java API up and running! I've called it rainbowduino-v3-streaming-firmware since it's only feature is to receive RGB frames via a serial connection of the build-in USB connector. You can find it at https://code.google.com/p/rainbowduino-v3-streaming-firmware/ if you want to use it for your own projects.

A Rainbowduino V3 controller attached to one of my custom build LED panels

How does it work?

The firmware expects four frame fragments to be send to the controller to be able to show one 8x8 24bit RGB frame. Splitting up the frame into four fragments is done to avoid running into data corruption / data loss as soon as the internal buffer of the Rainbowduino V3 controller runs full. It took a while to understand that the recent Arduino 1.0 update has reduced to buffer size from 128byte to 64byte although most of the blog and forum posts you'll find in the net are talking about a 128byte serial buffer - but that's a different story. Each frame fragment gets extended with a header and some checksums to be able to implement a reliable serial protocol including some proper error handling. Whenever a frame fragment was received an ACK reply message is send via the serial connection to the Java API. The firmware itself just holds two frames in memory: the one that is currently shown by the LEDs and the next one that is currently being received via serial. As soon as a full frame has been transferred the frame buffers do switch. Everything was held rather simple since the firmware should just accomplish a single job: Receiving 8x8 RGB frames and drive the LEDs with it.

The most painful problem I had to solve were those two conflicting interrupts I've mentioned earlier. In the beginning I could either decide to receive all frame fragments in a reliable way but suffering from ghosting / flickering effects at the same time since the timing while driving those RGB LEDs wasn't reliable any more. This was caused by the serial interrupt stopping the LED update routine whenever serial data was received. The other option was to keep the timing of the LED update routine evenly but dealing with data corruption / data loss whenever the controller was busy with pushing color data to those LEDs. This problem kept me busy for several month and I've tried multiple things to get around it including some frustrating moments when you have to revert all of your code changes since your new idea on how to solve this problem didn't turned out to work as expected.

At the end the solution to address this interrupt problem was to simply re-enable the global interrupts of the AVR micro controller inside of the just running LED update interrupt call. First this sounds like a stupid idea to allow a single threaded micro controller to again call interrupts although the currently running interrupt callback isn't done yet - this kind of smells like an interrupt calling itself over and over again which will brick your controller. In my case there's only the internal serial interrupt that is able to interrupt the LED update routine to be able to handle incoming serial data. This combined with the fact that the runtime behaviour of the LED update routine is very predictable since it only pushes one of the frame buffers to the driver ICs prevents the controller to run into interrupt loops. It took a while to figure out the best working timing and interrupt configuration but afterwards the LED update routine is only interrupted very shortly whenever the controller has to handle incoming serial data. The time between the next call of the update routine is still enough to parse the incoming serial data and store it in the frame buffer. Since the LED update routine is triggered every ~1250µs the controller also doesn't have enough time to neither receive a full frame fragment nor parsing it completely so that there's no risk to run into problems with the 64byte build-in serial buffer that would otherwise result in data corruption and data loss.

After fixing the interrupt problem the firmware is now able to run at up to 35 frames per second. Starting from ~38fps the timing between the Java API and the firmware gets wonky which results in lots of frame (fragments) being dropped by the firmware. Nevertheless 35fps should be more than enough for most usages. Also keep in mind that the internal refresh rate of the LEDs is close to ~100fps so that even if you stream frames with only 35fps to the controller the actual frame is pushed almost three times to the LEDs by the driver ICs. Therefore I'm currently not able to see any flickering at all while showing frames on the Rainbowduino V3 controllers. Another advantage is that this approach scales pretty good while using multiple Rainbowduino V3 controllers at the same time since even a single USB connection has more than enough speed to drive multiple controllers. I my case I even use all eight controllers directly attached to a single USB hub without any noticeable latencies of the USB connection. To not create any new bottlenecks in the Java API the RainbowduinoV3.java class was implemented in a thread-safe way so that more than one thread can drive multiple controllers at the same time.

Also I've tried to keep the Java third-party library dependencies down to a minimum so that you're not forced to use bigger frameworks like Processing just to be able to send RGB frames to a Rainbowduino V3 controller. It only depends on the RXTX, Apache Commons Lang 3, and the Simple Logging Facade libraries. If you need more technical information on how to use my rainbowduino-v3-streaming-firmware than please consult the technical documentation available on the project homepage. I've also provided two simple examples on how to use the Java API of the firmware so that you should be able to get your controller running without writing a single line of code. Those examples are also able to drive more than one Rainbowduino V3 controller at the same time.

For my 512 RGB LED coffee table project this means that I can focus again on finishing the remaining hardware tasks of the table itself so that I finally will able to use it as a coffee table in the near future! I'll keep you informed as soon as this happens

Sharkoon SATA Quickport USB3.0 XT before/after moving the on/off switch from the back to the top part of the docking station

While searching for an USB3.0 docking station for 3.5" SATA hard drives the SATA Quickport XT USB3.0 offered by Sharkoon got my attention at one point. It's simple, not that pricey and doesn't take up too much space. One of the things I was looking for was that it should provide an on/off switch so that you don't have to rely on the operating system to suspend the disks which usually depends on how well the SATA<->USB bridge inside the docking station is supported. What I don't understand is why Sharkoon places this switch on the back of the docking station so that it can't be reached easily if a disk is inserted into it - this kind of sucks if suspending the disk via the operating system doesn't work reliable. But luckily the top part of the docking station isn't used by an eject button, activity-LEDs or anything else except the imprinted Sharkoon logo - guess where I've moved the on/off switch to

Internals of the docking station incl. the cable connection of the on/off switch

It's not really a tricky modification to shift the on/off switch from the back of the docking station to the top part since luckily the cable that connects the switch to the main board is long enough. Also it can be disconnected easily from the main board since it's using a 2-pin connector. Therefore it's all about mechanical work without any soldering involved. First your have to remove the four screws on the bottom of the docking station which are hidden behind the housing foots. Lift them carefully with a slot screwdriver so that you can reattach them afterwards.

After all four screws have been removed you should be able to lift the top cover from the bottom part of the docking station. Be careful with the front panels activity LEDs since this transparent plastic piece sits pretty tight on top of the small LED board. If you didn't mess up at that point you should be able to see the internals of the docking station as shown in the picture on the right side.

After disconnecting the on/off switch from the main board I again used a slot screwdriver to push down those clamps on the two sides of the switch which keeps it in position. Again be careful to not break the clamps since you'll need them to keep the switch in its new position in the top part of docking station. After you've removed the switch from its original location pick your favourite handheld power tool like Proxxon, Dremel, etc to cut a hole in the top part of the docking station with the same dimensions as the original hole on the back.

The new hole for the on/off switch in the top part of the docking station

If you'll pick the same location for the switch as I did as shown on the picture above you won't have any problem with the length of the cable connecting the switch to the main board. It will be a bit more tricky to reassemble the docking station since you have to be careful to not tuck the cable between the top and bottom part of the docking station. But after all it should fit quite nicely without being forced to extend the cable or anything like that. Put in the four screws on the bottom, reattach the housing foots and you're done and can enjoy an easy reachable on/off switch mounted on the top part of the docking station.

The 512 RGB LED coffee table after its first test assembly

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 8x8 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.

A closer look at the smoked glass with the white Polystyrene grid below it

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 8x8 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 8x8 LED array. So from time to time you get the impression that a single row of an 8x8 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.

The table with its side board removed exposing the Polystyrene grid, the LED arrays and the technical compartment

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.

8x8 RGB LED arrays closeup

Since my last post about the audio system installation of my 512 RGB LED Coffee Table project I've spent my time finalizing the table internals needed to operate the eight LED arrays inside the coffee table. This includes the power supply, the micro controllers used to operate the basic table functions, the Mini-ITX PC that generates and distributes the to be shown images to the eight LED arrays as well as the needed wiring between the individual components and the front panels used to operate the table.

Overview of the RGB LED coffee table internals with all 8x8 LED arrays removed

The power supply of the coffee table divides into three sections:

• A small 12V standby power supply used to operate the tables micro controllers that do take care of starting up the other two parts of the tables power supply.
• An ATX power supply that serves the Mini-ITX PC as well as the Rainbowduino micro controllers on the LED panels.
• The internal power supplies of the stereo amplifiers and a small power supply for the active subwoofer crossover.

The 12V standby power supply, the PCs front panel connector and the USB hub in the background

The ATX power supply as well as the power supplies of the sound system can be independently controlled by two FS20 remote power switches. The tables main micro controllers do use a FS20 sender and a receiver module to be able to trigger and monitor the states of those power switches. One of the four channels offered by those modules is used as the main power switch of the table which triggers the micro controllers to power on the Mini-ITX PC. Therefore the micro controllers needs to be able to trigger the PCs power switch which is done via an opto-coupler so that the micro controllers don't inject any dangerous voltage levels via the power or reset signals that might harm the mainboard.

Beside controlling the power supplies the main micro controllers also take care of the front panel that provides several buttons to the outside world so that it's still possible to manually power on / off the individual table components. The front panel will also provide technical controls for the LED panel micro controllers so that I can flash a new firmware to them without being forced to dismantle half of the table.

The Mini-ITX PC, the ATX power supply and the two FS20 remote power switches

The third job of the main micro controllers is to drive some additional LEDs via PWM signals that are used to lighten up the four compartments of the table triggered by reed switches hidden inside the doors of each compartment. So whenever you open one of the doors some white LEDs mounted into the ceiling of each compartment will be dimmed up. For those two technical compartments that do contain the Mini-ITX PC as well as the sound system the LEDs will only illuminate the front panel itself and not all the electronic bits and pieces hidden behind it. I've also installed eight RGB LEDs into each speaker stack that are also controlled by the main micro controllers. The idea here is to have some lightning effects inside the speaker stacks that should be in sync with the just played audio signal. The hardware for doing so is ready but it still has to be implemented in software at one point.

The main micro controllers, the FS20 sender and receiver modules and parts of the fan control boards

The fourth and last job of the tables main micro controllers is to control the four fans that are mounted into the bottom of the tables technical compartment. Two of those fans will suck cold air into the central technical compartment - the other two fans are used the get the warmed up air out of the two lower technical compartments that do contain the Mini-ITX PC as well as the sound system. Since I can't really predict the heat generation of all electrical components I've oversized the ventilation system on purpose and installed some DS18S20 temperature sensors in the critical parts of the table. With those sensors the main micro controllers are able to decide if all or some of the fans have to run to get the warmed up air out of the table. The warm air will be conducted through several holes in the LED panels, through the Polystyrene grid and finally through a ~1cm gap between the smoked glass and the surrounding wood panels of the table.

The main power distribution board containing the connectors to the eight Rainbowduino micro controllers

The next step is to bring the table to a state that all parts except the front panels have been put together so that I can get a first impression how the table will actually look close to its final state. I'm pretty sure that the initial assembly will show up some smaller - hopefully no bigger - problems until the table itself is finally done. After that there's still a lot of work need to finish the software - especially since I doubt that I'll call the software 'finished' at any point in the near future since there's usually always something that you want to change or improve

The coffee tables sound system in the original and installed state

Quite some time has passed by since my last blog post about my 512 RGB LED Coffee Table project so that it's about time to give you a brief update what has happened the last ~8 weeks. Mid of September my carpenter was done with constructing the coffee table so that I could finally start to integrate all the electronic components and the needed wiring into it. Thanks again to especially Gunnar Schwinn from http://www.massivholz-moebel-schreinerei.de/ which did a great job in bringing my ideas to life and giving valuable feedback. As soon as the coffee table arrived at my place I focused on the sound system since the installation of it is rather a standalone task beside the installation of the RGB LEDs.

Thomann THE T.AMP S-100 2x100W Stereo 19″ PA amplifier

The sound system consists out of two Thomann THE T.AMP S-100 2x100W Stereo 19" PA amplifiers that have been 'optimized' to fit into the table. 'Optimized' in that context means that I've chopped both amplifiers in half, cut the housing into several pieces that do allow me to fit the circuit boards into one of the tables 20x23cm technical compartments. The power transformers were mounted against the compartments sidewalls and the cables to the front panels providing the volume regulators have been extended to fit my installation. It's just the average modifications that makes every DIN-Standard-evaluator start to cry - instantly.

Each stereo amplifier will drive a QX-62 two-way- and a QX-6.2W kickbass speaker pair from ESX that are meant to be installed into car hifi setups. Since I only have a stereo sound source I had to find a way how to connect both stereo amplifiers together. This is aggravated by the fact that all four speakers will be installed into relatively small compartments which will make it even harder to calibrate the speakers to deliver an acceptable sound. To do so I've installed a Reckhorn S-1 active subwoofer crossover that allows me to finetune the exact cutoff- and crossover frequencies between the two stereo amplifiers so that I can operate the kickbass speakers only in the desired frequency range and that the two-way speakers don't have to handle those the lower frequencies.

The four speaker compartments after they've been damped with bitumen plates

The installation of the speakers was quite work-intensive since I first damped the speaker compartments with some bitumen plates to prevent the wood from picking up the vibrations. Afterwards I've glued them into the table so that I was able to mount the speaker chassis itself. To tighten up the sound I've also muffled each speaker compartment with a bigger piece of insulating material since especially the kickbass speakers would usually need a larger compartment volume than my ~2.5l compartments can offer. As a final step I've installed two bass reflex tubes into each compartment to give the speakers some air to do their thing. Although those two bass reflex tubes are a bit oversized for the compartments a prototype compartment with only one or none bass reflex tube wasn't able to deliver a better sound in my opinion.

One of the two speaker stacks with a two-way speaker on the bottom

At the end a two-way- and a kickbass speaker have been stacked on top of each other as shown on the picture. Both speaker stacks have been installed between the bottom plate and the base plate of the tables technical compartment that does contain all the wiring needed to drive the RGB leds. To allow the sound to get out of this confined place a 45° cone between both speaker compartments does reflect the sound of the two-way speaker to the outside. Since I wanted the speaker stacks to appear as a single unit the space between the compartments will be covered with acoustic cloth to get a cleaner look.

The most work-intense part was for sure the modification of those PA amplifiers so that they do fit into the table at the end. Beside constructing a housing out of the original 19" enclosure I also had to extend some wiring to be able to connect the front panel controls and the power transformers to it. Also I've disassembled the subwoofer crossover and cut its circuit board in half so that I can mount the potentiometers to the front panel. The other half of the circuit board containing the power supply for the active subwoofer crossover is mounted inside the technical compartment of the coffee table.

Mounted amplifiers with extended front panel wiring and installed power supply

After the first tests I'm pretty satisfied with the sound of the coffee table especially since this was my first attempt to build anything like this. Of course there isn't a massive bass foundation coming out of the table but this was expected since I only used 16.5cm car hifi speakers in a very limited environment. Usually you would need a lot more space to construct an usual subwoofer compartment. Nevertheless due to the combination of a full-range two-way- and a kickbass speaker pair the table is able to deliver an more than acceptable sound from my point of view.

Be advised that applying those kind of modification to consumer hifi / PA devices do require a broad knowledge of electronic components in general. Please be aware that you can easily end up in a life-threatening situation since you have to deal with line voltage directly at several places while doing those kind of modifications. Therefore I have to close the post with:

So, things you shouldn't do #3: Cut 19-inch amplifiers and subwoofer crossovers in half

If you need to find out which CentOS version you're running you should have a look at the content of the following file:

You can use yum to get a list of all currently installed PHP packages so that you know which packages of the AtomiCorp PHP installation you have to install and which one you might have to install manually:

Now that you're aware of which RPMs are currently installed we can install the alternative PHP installation provided by AtomiCorp following their installation instructions. First we have to install their repository definitions to allow yum to download the new RPMs:

Since I also want to upgrade my MySQL installation from the CentOS default version 5.0 to 5.1 I added also the mysql package to the yum update command:

This results in the following packages being updated or installed due to additional dependencies of the new PHP and / or MySQL versions:

After yum has successfully installed the new PHP version you might want to disable the new AtomiCorp Repository to not interfere with the usual CentOS updates. To do so you have to edit the following file and set the enabled property to 0:

Now you should be able to call the PHP interpreter to check for the PHP version:

So version 5.3.6 is now the default PHP version of your CentOS installation. But as stated by the PHP interpreter you also have to update you php.ini file to fit the new PHP version:

Be sure to update all custom settings of your old php.ini file to the one provided by the new RPM packages. After this has been done you should be able to call the PHP interpreter without an error message complaining about deprecated configuration values:

In that context you might want to set the default timezone for all date functions which is a behaviour of PHP that has changed from version 5.1 to 5.3. To do so you have to find the line containing the date.timezone property and set it to your desired default timezone:

Since we've also updated the MySQL installation from 5.0 to 5.1 we have to upgrade our existing databases to the new MySQL version. MySQL should still be able to start up without those upgrade tasks applied to it but it will remove several errors from the MySQL logfiles. To do so you have again to backup you existing main MySQL configuration file and replace it with the new one:

Again make sure you adapt all old settings to the new MySQL configuration file. To upgrade your existing databases to the new MySQL version you just have to call the mysql_upgrade command which will than connect as the root user to your running MySQL instance to apply the needed upgrade statements. If you don't know you root password or if you don't have local root user access set up in your MySQL permissions you could just call the mysqld_safe script with the --skip-grant-tables parameter to allow full access to your MySQL instance and apply the upgrade statements afterwards:

After that you should be able to start up your upgraded databases without any errors in the MySQL log file. For my CentOS 5.6 installations I wasn't able to find any problems after upgrading PHP following this Howto. I'm still able to install any CentOS RPM that has a dependency to the original PHP version of CentOS since the names of the RPMs haven't changed. Of course you should check your currently used web applications that they are compatible with a PHP 5.3.x installation which is also the main reason that the RHEL/CentOS guys decided to provide PHP 5.3.x as additional packages since some of the provided web applications still depend on a 5.1.x PHP version. But if you're sure that you don't want to use any of those older web applications I'd say that this Howto is the easier solution to upgrade your PHP installation instead of dealing with two PHP installations at the same time.

Eight 8x8 RGB LED arrays each driven by a Rainbowduino Controller

Finally! After hours spend with fitting LEDs into reflectors, preparing cables, cutting shrink tubing pieces and soldering everything together to 8x8 LED arrays: It is done! And I'll never ever do it again this way. As I already stated in my first blog post about my 512 RGB LED Coffee Table project I was a bit too optimistic in the planing phase regarding the wiring effort needed to get all LEDs working.

When I've started the first of the eight 8x8 LED arrays I wanted to wire the LEDs in a nice and isolated way. Therefore I've wired all red, green and blue LED pins with coloured cables that have been stripped on several places for about ~1cm so that I can solder a LED pin against it. After that I covered every solder joint with a piece of shrink tubing to avoid potential short circuits. The idea did sound good in the beginning. But after finishing the first LED array I realised that building one 8x8 LED array has taken me ~10h! Ouch! I didn't really expected that it will take that long but on the other hand it's quite obvious why:

• 64 RGB LEDs with 4 pins each
• 64 reflectors
• 16m of wires cut into 64 pieces
• 256 solder joints between wires and the LED pins
• 288 pieces of shrink tubing
• 32 cables for connecting the Rainbowduino controller to the LED array
• 64 solder joints between LEDs and the Rainbowduino controller

After I had finished the second LED array using the same approach I was able to reduce the overall build time to ~8h which was still to much in my eyes. At the beginning of building LED array #3 I was so sick of it all that I've tried to save the time needed to strip the wires with burning away the isolation of the cables with my soldering iron. After the probably toxic fumes made my head swim I had to stop this and come up with another way of wiring the remaining 5 1/2 LED arrays. At this point I was quite frustrated and even thought about dropping the whole idea for a short moment.

But instead I tried my luck with PCB stripes used to connect the red, green and blue pins of each LED in eight rows per array so that I don't need any wires and shrink tubing pieces to connect them. For the common anodes of the LEDs I used eight pieces of copper wire to connect them together. This approach really simplified the wiring effort to connect all 256 LED pins in a 8x8 matrix circuit. Therefore I only had to prepare 32 wires for connecting the PCB stripes / copper wires to the Rainbowduino controller. The overall build time did reduce to ~5h using this approach - not bad! The drawback is that the whole circuit isn't isolated any longer so that I have to be more careful to not ending up with any short circuits that might brick the controller.

LED array #1, 'The Ugly #3' and #8

In the meanwhile I finished all 8 LED arrays with some help of Boris Bernhard (thanks again, bud!) so that I can continue working on bringing them to life together somehow. The picture shows the LED array #1 that I've build using the old approach, LED array #3 aka. 'The Ugly #3' since it's a mixture of the old and new approach and therefore looks really messy and LED array #8 where practice allowed me to build it in almost under ~4h. If I would have to build eight 8x8 LED arrays again than I wouldn't start with MDF boards this time. I'd rather spend some additional money to order some custom made PCB boards ready to be equipped with the LEDs providing all the needed wiring, cuttings and connectors for the Raindbowduino controller. I'm pretty sure that the money spend for those PCB boards would easily compensate the saved time to build the LED arrays like I did the last months. Lessons learned. Nevertheless here's a quick video showing one LED array running a demonstration loop based on a firmware by seeedstudio.com that I've extended a bit:

So my idea to bring those LED arrays to life is to use a rather simple drawing routine in every Rainbowduino which will be connected via a two-wire interface to a central Arduino controller driven by some Java code running on a small Intel Atom board. Main motivation for this approach is that I'm not too interested in programming micro controllers and rather prefer to write the actual code on a normal Linux computer using Java. It will also be much easier to integrate the whole installation into a local network, to control it with more than one frontend or to use the power of the Java Sound API to interconnect the table with MIDI devices, etc. After searching the net a bit I've found beside mostly specialized code for specific Rainbowduino-based projects an very interesting project called PixelInvaders that tries to control multiple output devices like Rainbowduino controllers or LPD6803-based boards with one piece of software. The projects page also offers (prefabricated) 8x8 RGB LED panels called PixelInvaders Panels that do use LPD6803 ICs to drive the LEDs. The program able to control those panels and all other supported output devices is called PixelController and it follows the rough idea I had in mind to drive my eight LED arrays in a pretty similar way. Instead of reinventing the wheel once again I decided to give it a shot and to get a bit involved into this project myself. That's what the author has to say about his project:

PixelInvaders is an open-source hardware project for artists, geeks and YOU! The PixelInvaders LED system consists of 3D RGB LED panels, that are capable of playing back real-time generated video animations or simple color changes. Multiple PixelInvader panels can be connected with each other to form a panel of any size. The panels are based on the latest LED technology - besides low heat dissipation and long life, a panel may illuminate an entire room and consume less energy than a standard lightbulb! PixelInvaders panels are perfectly used as effect lighting in clubs, bars, fairs, museums, on stage, in a lobby or in your living room. The control software "PixelController" generates the video animation in real time. This has the advantage of video animations that are synchronized to music. PixelController is released as open-source project on GitHub.

Right now I'm busy trying to get my LED arrays to work with the PixelController software. Also the construction of the coffee table itself should be done any day so that I could start to bring everything together. Therefore stay tuned for another update of my 512 RGB LED coffee table project

512 RGB LED Coffee Table

"Wait.. What?! Are you serious?" "Yes, I am!" "Why do you want to do that?!" That's actually a very interesting question - and it's the usual response I do get if I explain what it's about those weird pictures I post on Facebook about prototyping loudspeakers or drilling 2,560 holes into plywood boards. Also people don't quite understand why I've spent hours and hours with constructing a 3D model of a coffee table. This is a first attempt trying to explain myself why I'm spending my free time for this project since more than 6 months now.

During 2009 / 2010 several projects got popular in the Internet where guys used various micro-controllers to drive (RGB) LEDs installed in some sort of coffee table. A lot of those guys seems to be inspired by Daft Punk since they did use the patterns shown by those tables during their live performances. A German example of such a project is 64 RGB-LED Couchtisch that did use TLC5940 ICs to drive 64 RGB LEDs from a micro-controller. Those TLC5940 are a quite easy way to drive multiple LEDs using a serial connection that can also be daisy chained. Also the Arduino platform does offer a library for this IC. Sadly the number of TLC5940 that can be dasiy chained is limited by the time the micro-controller needs to update all ICs via the serial interface. For a 64 RGB LED installation it's a suitable solution since you 'only' need 12 TLC5940 ICs to drive those 64 RGB LEDs but I wouldn't use this approach for bigger setups. That was one of the main reasons for me to not following up the idea to build such a table on my own those days.

Than in late 2010 I've stumbled upon a piece of electronics offered by www.seeedstudio.com: An Arduino based board able to drive 64 RGB LEDs with all the comfort of the Arduino platform and without the need of any external wiring? I for sure had to get my hands on this controller called Rainbowduino. After reading the basic documentation I was pretty confident that this piece of hardware is suitable for driving larger numbers of LED arrays since the Arduino platform allows you to easily interconnect multiple controllers - for example with a 2-wire serial protocol offered by the Wire library as one of the many available Arduino libraries. This sounds like the perfect playground for someone like me which isn't really interested in low-level micro-controller programming and is more excited about programming fancy animations and patterns in a high-level programming language. So while having some days off after Christmas 2010 it was unavoidable that I had to continue developing my idea of building a coffee table that uses RGB LEDs to illuminate it's glass top.

Since I wanted to go bigger than 64 RGB LEDs I thought about doubling the number of LEDs which lead to a 16x16 LED setup resulting in 256 LEDs in total organized in four 64 RGB LED groups each driven by a Rainbowduino controller. As I didn't wanted to build a quadratic table I added another set of 256 LEDs to it which end up in 512 LEDs in total driven by eight Rainbowduinos. Wow, that's quite something - and I didn't realized those days how huge the wiring effort will be for this setup. Based on that idea I've started constructing a coffee table around it. Each RGB LED should light up a 4x4cm area on the glass top which lead to the overall dimension of ~140x70cm. Since the needed electronics to get this table running also takes up a bit of space I decided to start constructing a 3D model of the coffee table. This model made it for sure easier to find potential problems I haven't thought about so far and it helped a lot to get an overall impression on how the table will look like.

512 RGB LED Coffee Table Internals

So here's a quick tour through the latest model of my still to be build RGB LED coffee table: The first picture of this post gives you an overall impression on how the table will look like. After checking out a lot of wood board samples I decided to go with North American Walnut boards for constructing the main table out of it. The table will be covered by a smoked glass which will have a satinized foil attached underneath it so that you can't see the tables internals. The foil also helps to diffuse the light emitted by the LEDs. The main table seats on two floor units that mainly will store all the needed electronics. So that the table wouldn't look like an upside down 'U' I've connected both floor units with a central bottom panel. The two square pillars that are barely visible in the picture between the bottom panel and the main table will contain loudspeakers so that you can play some music while the table shows your newest psychedelic music visualisation pattern. The second picture shows another shot of the table where you can see some of it's internals with the glass top partly removed. Below the smoked glass you'll see a grid constructed form 3mm Polystyrene panels which separates every RGB LED in it's own 4x4x15cm compartment. Below this grid eight ~35x35cm MDF boards will be installed where every board will hold 64 RGB LEDs. Below those eight LED boards a technical compartment will contain all the needed wiring and micro-controllers to operate the table.

The current status is that the table is being constructed by my favourite local carpenter www.massivholz-moebel-schreinerei.de specialized on solid wood cabinetry. I didn't try to build the table on my own since I wouldn't be able to build it in a way that it doesn't fall apart at the end or that it doesn't look like the work of a bungler. The last months I was quite busy with soldering the LED boards and prototyping the other remaining circuits. I haven't really started yet to work on the needed software for the Arduino controllers - I only have some demonstration code to test the LEDs on each LED board and I have a prototype running that instructs a Rainbowduino micro-controller via the Wire library from another Arduino controller. So there's still a lot of work to do and I will continue to report about my plan to build a 512 RGB LED coffee table.

...and coming back to the question from the beginning: "Why do you want to do that?!" I still don't know yet.. but stay tuned for a potential answer in the near future