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.
Video (Part 1)The Basic ApproachSo, 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 touch sensitive. You can see in this video that it activates (the red LEDs on the sensor boards) even when there is no interaction.
Video (Part 2)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.
ThoughtsMy thoughts on using the system and how it changed the experience over using more typical development boards:
- Debugging when I accidentally blew out a drive FET was a lot easier than if I were building on a monolithic connector. I could easily just swap out one driver for another and make sure the IO was not damaged and I could verify that it was the module consistently not working instead of having to probe things to sort out what was happening.
- Creating modules is a lot easier than building on a controller directly. Having the power on hand and just more needing to look at how to locally buffer it is a much more simple approach than trying to do a single design with a bunch of the same things. Just having a clear number of IO was easier to consider how to approach the design. Perhaps this is my perspective, but I think this mimics how most designs are created, one block at a time.
- I can see that doing a combined (monolithic) board schematic would be just a matter of taking modules and putting them together with the rest of the system components. I'm sure for many this isn't a brilliant insight, but for me I can see how this will help to make a faster process for electronics development that can be a more systematic approach. You would be able to know that individual blocks were tested to work, so the changes would be things like how the system power is coupled or decoupled and how layout impacts performance.
- If we spend some time with the system level software, it would really either make the system easy to use or not. I'm using this at the level where I'm having to set up all pins manually and the only examples that are related are based on other boards, so the going is a little slow. If we have a large number of tested examples plus simple system naming for pins it would be pretty awesome. One layer on top of this would be efficient drivers for specific things, like reading sensors or running a heater using the system PWM or similar. There are a lot of tricks that are either very low level or specific to a controller that would help a lot. One example, right now I'm just writing to each pin separately. On the other hand, it would be not too difficult to set up a simple function that would let a user assign values to specific pins and then efficiently push those states out using port level writes or even things like the bit banding that is available. I guess we are talking about effectively Ruby on Rails for microcontrollers, but hopefully with more focus on efficient resource use.
Next project will be using the same drivers to do a large panel and many touch sensors.
If you want to find out more about the Atomo parts used in this build, please go to http://atomosys.com. If you get there this week (by March 12th), you can get an extra 10% off the first order when we launch on IndieGoGo.
Comments