I just got the whole Atomo line final prototypes back and we kicked the tires to make sure they were at least functional. I needed something to really test the concept of the design approach for the system, so I picked up 40m of RGB LEDs in Shenzhen and proceeded to put something together.
So, I started with building a single module to drive as many LEDs as I could from one card. The limitation was that I wanted to do a non-matrixed display, so 1:1 drive for each IO control signal. I've got up to 8A of power for each module to work with, and I had 6 pins of GPIO that could drive, so we are looking at a max of 12V (the limit for the LEDs I had) and about 1.3A per each channel. The first test module allowed for way more than that, and then I designed a PCB version with slightly smaller FETs that will only handle up to around 4A each.
After making sure the basic approach worked, I started looking at what to do next.
I had a lot of LEDs to do something with, but what? I decided to do a 1M 4x4 square panel with touch interface. So, I designed both a driver module with sensing input and a board for assembling LED strips into a square matrix.
You can find the project on github: https://github.com/jonbuford/atomo_projects
After I sent those off, I started looking into getting the other bits together for doing the panel assembly and realized I might want to start with something a bit smaller for portability and testing.
So I assembled a smaller 4 X 4 matrix and used two touch sensors. And in the meantime, my parts I ordered for the original design had a missing component, the touch sensor, so I had to scramble to find an alternate supplier and lucked out. I ended up finding the Azoteq IQS127D sensors and demo boards, which added proximity and touch sensing (the original Atmel parts were just a single event). Sensing the two events was done using a voltage divider network on an analog pin (there are two per module). The IQS127D pulls the pin low when the event occurs and holds it low as long as it is still happening or until it times out. So, the input is biased to 3.3V and then there is a resistor to limit the current and a resistor between the output and the proximity sensing. I think for this prototype build I used a 2.7K Ohm resistor for both. The touch event pin is connected directly to the output. It floats unless it is active low, so this means that the pin will be at 3.3V, around 3.1V on proximity sensing, and ~0V for a touch event. It would be good to find a better value for the voltage divider values to get the proximity sensing to perhaps 1.5V to make it easier to tell apart from the other two states. Another approach for this, as long as you have a sufficiently high resolution ADC, you could wire more than one sensor up in this same way using a resistor ladder network.
If you are reading this at home and want to create a panel like this, the configuration really is up to you. It would have been much easier to just do single strips instead of squares, but these LED strips just need power supplied and the separate ground for each color to work.
I assembled a letter sized breadboard layout of 16 9-LED squares, which would give me a reasonable approximation of what the larger panels will do, and put it all together once my boards came back.
It was a lot of hand wiring, but it worked. The touch sensors, I didn't tune the sensing at all, so the proximity sensing is a touch sensitive. You can see in this video that it activates (the red LEDs on the sensor boards) even when there is no interaction.
This can be tuned by modifying the wire loop configuration and size, with changing the capacitors on the boards, and the chip configuration settings. These settings, not that I used them, were the main unique point over other solutions that I found out there. For inexpensive sensors, they are very full featured.
So, how are we powering all of that? I used the 8 module controller and connector board and the dual ATX power input, which would allow for a max of 768W in theory (8 modules, 8A, 12V). This panel only uses around 96W at full tilt, but the full size panel I have planned will push the whole thing to the limit of the power supply, should be fun.
The controller shown above is from our last prototype build. After we ran these, we found that the Pi-compatible 26-pin header was inverted, so it is installed backwards here, and we wired it up so that the JTAG headers could be accessed by the Pi for flashing via OpenOCD. The production version will remove the separate 10-pin headers to save board space, but they will be accessible via the 26-pin header either directly or using an adapter to break them out for a standard pinout.
My thoughts on using the system and how it changed the experience over using more typical development boards: