Does this project spark your interest?

Become a member to follow this project and don't miss any updates

Waterfall Wall with LED Illumination

A translucent wall with custom shelves, a waterfall feature, and remotely-controllable lighting

Similar projects worth following

This project was created on 05/06/2014 and last updated 4 months ago.

We wanted to use an open area near our front door to homeschool our kids, but we wanted a way to visually separate the area without blocking sunlight for our entryway. We built custom shelving 12 feet long, with translucent glass above to allow light through. We also want to have water running down the glass, as well as remote-controlled LED lighting.

The plan is to create a Python application that accepts user input for control of the lighting. The commands will be sent over a network to a Raspberry Pi. The light control data will then be sent wirelessly via nRF24L01 modules to an MSP430 Launchpad at the Waterfall Wall, which will control a strand of WS2812B LEDs. A custom circuit board will enable control of AC power for the water pumps, and 3D Printed parts will be employed as needed.

I also intend to document the plans for shelves themselves, which I've designed for sturdiness, ease of assembly, low material cost, and low material waste.

The Waterfall Wall with LED Illumination encompasses many different domains including electronics, woodworking, programming, plumbing/water management, and 3D modeling/printing. Consequently, it is challenging to capture the comprehensive capabilities and characteristics in a consolidated design document. In recognition of the emphasis Hackaday places on the connected nature of devices, my primary focus will be on the electronics and programming portions of the effort with the hydro-mechanical aspects playing a supporting role.


System Design Document

Below is the design document showing how user input data moves  from a convenient control interface toward changing the state of LEDs and controlling water pumps. It is a perilous journey, taking two hops over the air and ultimately dealing with high voltage (for the AC-powered pumps) and high current (for the LEDs). The "connected device" requirement is met through multiple wired, wireless, and software data transformations (e.g.: User interface -> Python data handling -> Telnet -> 802.11 -> Ethernet -> Python data handling -> SPI -> 2.4GHz wireless of some kind -> SPI -> MSP430 data handling -> WS2812B protocol via SPI)

At the moment, the system is very much in a prototype configuration: there are jumper wires going to each nRF24L01+ wireless board, the MSP430 Launchpad is only intended for microcontroller prototyping & development, and the ProtoPowerSwitch board is intended for prototyping and development of circuits interacting with AC mains voltages.

As of 11 August 2014, the main design path has been verified operational; that is, I can use a Python color picker app on my laptop to control the LEDs by sending data along the path shown in the system design document.

The next step will be to design and build circuit boards to get all the capabilities into a much smaller and more product-like package. After the boards are designed and sent out for fabrication, I will have a good opportunity to modify the software codebase (on the laptop, on the Raspberry Pi, and on the MSP430) to improve the capabilities of the final system and make the code more clear/documented/useful to other open source hackers.

Open-source licenses and permissions

This project would not be possible without the support and examples provided by many, many open source contributors:

LED controlling software for MSP430 was derived from GitHub user RoXXoR with no license specified; GitHub T&C includes rights to view and fork.

The color picker Python app is derived from the wyPython cubecolourdialog created by Andrea Gavana, licensed under the wxPython/wxWidgets/wxWindows license

The MSP430 wireless code is derived from nRF24L01+ Library for MSP430 provided by GitHub user spirilis under ISC License

Python is licensed under the Python License

Raspbian is licensed under the GPL.

Quick2Wire for the Raspberry Pi is dual licensed under the MIT License and LGPL. is from GitHub user klalle with no license specified; GitHub T&C includes rights to view and fork.

miniboa-py3 (Python 3.0 Telnet server) licensed under Apache License, Version 2.0 (note, I had the same issue/fix found here), Server codebased derived from the included miniboa chat room example.

And this link (previously featured on Hackaday) was very helpful as well

  • 1 × MSP430 Launchpad with MSP430G2553 microcontroller (20 pin)
  • 1 × ProtoPowerSwitch: Relay
  • 2 × NRF24L01+ modules
  • 1 × Wire & cables (Ethernetcode , power cords, jumpers, hook-up wire, jumper wire)
  • 1 × Laptop Not dedicated to the project, but used nonetheless
  • 1 × Raspberry Pi single board computer, model B, with power supply and optional keyboard/mouse. Not dedicated to the project, but used nonetheless
  • 1 × Wireless router Mine is wired to the RPi and wireless to the laptop; not dedicated to the application, but used nonetheless
  • 7 × LED strip WS2812B, 0.5m length w/30LEDs Total length 3.5m, came all in one piece; best price I found was here:
  • 1 × Logisys Corp. 480W 240-Pin Dual Fan 20+4ATX Power Supply PS480D2
  • 18 × Wood 6ft. x 12” x 1” Plus some other wood and wood screws, more details later

See all components

Project logs
  • Go-Go-Gadget nRF24L01+

    4 months ago • 0 comments

    You know how sometimes you can take a device, plug it in, and it works exactly like you hoped the very first time? I wish I could say that happened for me with the nR24L01+ wireless module, but alas, for me, it was not meant to be.

    There were far too many variables involved, and far too much new ground to cover, such that it was inevitable I would learn things the hard way. On the positive side, by doing everything wrong the first time and solving each issue one at a time, I am now that much more familiar/comfortable with this wireless module and the MSP430 and Raspberry Pi libraries for it. I also have a greater appreciation for how minimal and well-designed the nR24L01+ wireless module interface is; while the numerous registers and instructions seemed daunting at first, they actually provide a well-balanced capability for a wide range of wireless setups.

    I'm very happy to report now that I have successfully transmitted data from my Raspberry Pi (running a Python 3 Program) to my MSP430 Launchpad (using MSP430G2553) wirelessly using nRF24L01+ modules! The code involved still shows a few battle scars from my debugging, but I should be able to clean it up and upload each program to GitHub so that anyone else can just download & run the code with minimal effort (note that there are still some setup steps for the Raspberry Pi that I'll detail, but at least the wireless configuration settings will match work right out of the box). Just a few of the issues I ran into while debugging were mismatched payload length, mismatched channel assignments, swapped pinouts, and backwards address byte order.

    At this point, I'm able to send data:

    • from a Python app running on laptop via telnet to a Python app running on my Raspberry Pi
    • from a Python app running on my Raspberry Pi to my MSP430 (verified via debugging data)
    • from my MSP430 to the strand of WS2812B LEDs

    While I've been using dummy data for the most part, at this point, I feel (personally) that the most significant risks have been mitigated as those were the main first time events for me. Going forward, I just need to take what I've done and work it into handling the actual data. Risks still remain, like bandwidth, timing (the MSP430 doesn't have the memory to store data for 200+ LEDs), and even power (the LED strand power traces may be undersized for the current at max load), but at least now I know that everything in my prototype system is hooked up properly and I can at least proceed with circuit board schematics, layout, and fabrication. Today is a good day.

  • ​Light ‘em up!

    5 months ago • 0 comments

    With the waterfall part of the project working reasonably well, I’ve moved on to the electronics side of the project, beginning with control of the WS2812B LEDs.

    To power the LEDs, I found it convenient and cheap to use an ATX power supply. At full power, each LED can consume up to 50mA, so for 200 LEDs that means I would need at least 10A at 5V. An ATX supply that can do this can be purchased for as little as $14 or salvaged for free.

    I plan to take apart the power supply later; if there is enough room inside, I may use it to house the final electronics as well. ATX power supplies need one of the pins pulled low to start operating (aside from standby power), so I created a shorting jumper by removing the ATX connector from an old motherboard and just soldering a wire to pull down the control pin. My preferred technique for connector removal is to add excess solder to the back of the thru-hole pins of the connector and slide a soldering iron back and forth along them to evenly heat up all the pins. After working it for a minute or two, the connector fell right out, and I used some desoldering braid to clean up the pins.

    The next step was to find a good way to communicate with the WS2812B LEDs. I wanted to use the MSP430G2553 microcontroller, as it comes with the low cost MSP430 Launchpad. I found a few resources which helped--some used the same microcontroller but older versions of the LED (e.g. WS2811) and some used the WS2812B LED but also used a more advanced MSP430 microcontroller. I decided to use the code designed for the more advanced microcontroller and port it back to work with the MSP430G2553. As it turns out, there were some differences with register names and available clock settings, but after getting acquainted with the MSP430 communication protocols and making some edits to the code, it worked!

    I've forked the original code and uploaded my changes to github here. Note that currently there is a limited to how many LEDs can be controlled because a buffer is used to store all the pixel data, and there is not much RAM for such a buffer on the MSP430G2553. I’m hoping when it is all working I can just stream the pixels in real time, mitigating the need for large data buffers.

  • I gotta have more!

    6 months ago • 0 comments

    The new pumps came in! I tried them out and they produce a much more satisfying flow. There are a few places where the water still groups together into streams, so I may investigate adding more holes or increasing hole sizes in those areas. Add that to the to-do list.

    I then cut and drilled tubing for the second trough; the process was very similar to the first one, but I happened to find a small leak in one of the 3D over-the-edge parts. Something else to add to the to-do list…

    I wanted to improve upon the duct tape solution to redirect water into the trough at the edges. I came up with the 3D model seen here at Thingiverse. It provides a small channel to catch the water coming down, and then it redirects water away from the edge, widening as it gets closer to the surface of the water. I superglued this piece onto the bottom corners of the glass and sealed it along the glass-plastic surface with a small amount of Silicone II.

    It works well for the most part, but there is the occasional stream of water that makes it over the edge and gets the wood wet; I’ll probably add a little more material to the surface to help contain all the water. I may need more paper for my to-do lists.  :)

    The "wood that gets wet" is 1 inch corner edging. It covers the rather unsightly edge of the plastic sheeting liner. A little backstory here....

    The liner is made out of two layers of 6mil plastic, and a black top layer made by cutting open a 3mil thick garbage bag (I really don’t want it to leak, so redundancy is critical). I filled the liner with water, then trimmed the plastic layers so that they ended at the top edge of the wood trough. I then taped the layers together with duct tape all the way around the edge. I nailed the lining into place along the top edge of the wood (nailing through the duct tape) about every 6 to 8 inches along the edge. The corner edging wood covers the plastic sheeting edge, duct tape, and nails along the edge of the liner.

    The wood corner edging on the long sides of the trough is rather straightforward to cut and doesn’t require anything special, but the ones along the short edges are rather oddly shaped. I marked the needed cuts with a pencil, and took a Dremel to it, revealing a final shape (which fits well) that looks like this:

    One last thing, I uploaded the first video required for the Hackaday Prize! You can find it here, enjoy!

View all 5 project logs


Mike Szczys wrote 6 months ago null point

Hi David, thanks for entering this in The Hackaday Prize. Looks like you already have a great start both on the build and on documenting the project.

I LOL'd about the laundry detergent. Reminds me of a prankster who dumped a bunch of soap in a fountain one day at the University I attended. Turned out like a foam party at Ibiza!

Are you sure? [yes] / [no]

infinityis wrote 6 months ago null point

Hi Mike, thanks for the comment. I too have seen soapy fountains while in college; I'm guessing this is a familiar occurence around institutions of higher learning. By the powers of correlation (and optimism), I must therefore surmise that the event has somehow enhanced the homeschool environment.

Are you sure? [yes] / [no]

Similar projects