Archive for the 'ACRIS' Category

Page 2 of 2

ACRIS communication fixed for realz this time(?)

I have been fighting with this problem for a year. I was so convinced that my board fix for ACRIS would stop the issue of the boards randomly stopping to process data. I thought I could fix everything by adding pulldown resistor to force the communication chips to be in read mode when the microcontroller wasn’t telling them what to do.

Wroooooooooooooooong. 🙁

Turns out, it’s a software problem. It’s always a software problem. Seriously. I encounter so many software bugs compared to electrical bugs, it’s not even funny. Well maybe a little bit, but whatever. Even if it isn’t a software problem, usually you can fix your problem in software.

I noticed that when I unplugged the communications links and plug the lines back in, I could force the lights to freeze. So, there was something going on with the RS-485 chip, I thought.

So, I immediately read the datasheets of the SN75176B (the TI chip I use) and the MAX485 (the RS-485 chip made by Maxim, which is over 3 times as expensive). “A-ha!” I told myself, “clearly the issue is that the SN75176B produces unknown voltages when the comm link is broken whereas the MAX485 guarantees a logic ‘1’ output.” Therefore, the AVR must be going a little crazy, stopping communication. I was so convinced that I even started writing a blog post on how much cheap stuff sucks before even testing my theory.

Okay, turns out that wasn’t the issue because I made a little test setup:

On this board are two AVR microcontrollers with corresponding RS-485 chips. The left microcontroller uses tha MAX485 and the right uses the SN75176B. Much to my surprise, the SN75176B was actually better at not dying when I started disconnecting and reconnecting the communications cables.

So what was going wrong? I investigated by having the debug LEDs show the various error registers. Turns out, sometimes when you disconnect and reconnect the cable, you get framing errors (FE0 in UCSR0A is on). But wait, there’s more! When the communication freezes, the whole AVR slows down to a crawl. A .1ms operation takes a good 10 seconds or so… very odd. My guess is that sometimes, a framing error occurs and the receive interrupt is stuck in a loop waiting for it to complete. As a result, the chip seems to be running slowly. By temporarily stopping the interrupts, resetting the UART, and re-enabling the interrupts, I can save the communications bus.

Oh, one more thing. For the rework I posted above, I used 10K resistors for the pulldowns. That was stupid; I should have tested things first. For the MAX485, 10K pulldowns are more than enough. But take a look at what happens when I first start up the SN75176B.

(You don’t want to know how long it took me to get that damn picture).

10K pulldowns are apparently too weak. After using a 1K pulldown instead, things looked much better:

I should have tested that out before I reworked my lights, but unfortunately, they’ll have to stay like that because I don’t feel like taking them down and fixing them again.

I’ve been running them for almost 9 hours now at the highest brightness with very fast communication and they haven’t failed once. So I think the problem is fixed.

ACRIS Board Rework: Fixing Faulty Communication

A while back, I identified a major issue with ACRIS’s communication network. The MAX485 chips that I use can switch between transmitting data and receiving data. To switch modes, you simply pull two pins either high or low. I tied these pins directly to the ATMEGA so that I could allow the LED controllers to talk to each other in future firmware revisions.

However, when the ATMEGA first starts up, the state of this pin is unknown, so a blip in the logic power can cause multiple devices to want to transmit data. As a result, the entire communication network just sort of stops. 🙁

But, by adding a simple pull-down resistor to those transmission-enable pins, it will make the default state of the MAX485 to receive data.

The rework on my lights was pretty difficult because everything was pretty tightly packed. But, I was able to remove the main body in order to get at the MAX485 chip.

Afterward, soldering a 10K pulldown resistor was not hard.

Re-assembling was a pain in the neck, though. I kept losing the plastic spacers and doodads.

The Road to ACRIS

Finally. After months of inactivity, I finally have ACRIS ready enough to show the world. This post is more or less an account of what I’ve done so far. The main project page has links to all the technical information, plus a ton of photos, especially on the page about the lights I designed. I’m going to summarize what I did in this post.

It all began in January 2011 when I was working on the Next House Party Lighting System (which had some pretty awesome results). As one of the project leads, I designed the electronics that powered the lights. The idea was simple: get output from a computer to a board, which would then control a set of high-powered LEDs.

Fast forward into February. We had a lot of problems with the boards I designed, but eventually got through them. I learned a great deal from the mistakes I made, and, armed with this information, I designed totally new boards. Over
the summer, I then got those boards printed, built them, and installed them into two lights. Now, I’m working on making more lights, writing software to make them flash to music and respond to other environmental inputs. What do they look like so far? See for yourself:

The LED controllers I designed are highly generic. They can be used for other projects! I want to make these boards highly available because I think they will help a designer focus more on the creative process when designing a light and less on the tedious engineering aspects. There’s a lot of potential for growth!

The big attraction for the boards that I designed is that they drive high-power LEDs, especially RGB LEDs. They’re notoriously difficult to easily drive, so this board does all the hard parts for the designer.

The Lights

I bought some lights at the hardware store and modified them to use my LED controller and 3 of these LEDs. IMO, they look quite classy.

I wrote up some documentation on how I modified these lights. There are a bunch of photos here.

The LED Controller

These boards are the fundamental part of the project. What do they look like? Like this:

Well, what do they do?

  • Take input from a computer or other source over RS-485 serial (on CAT-5 cable)
  • Drive up to 15 channels at 360mA each(!!!) with that data
  • They’ve got a custom bootloader (with some interface software), so you can easily reprogram and reconfigure the boards
  • You can power them in several ways
  • You can string them together to create a network of devices

I want to make these boards generic so that anyone can use them to make their own LED lights. They work best with high-power RGB LEDs (since there are 15 channels per board, that’s equivalent to being able to drive 5 RGB LEDs).

I also made this cute mini version. I haven’t tested it out, but it should be able to drive 5 channels. It’s like 1.2×0.8″ or something.


I’ve just finished designing this USB dongle that converts serial over USB to RS-485 to communicate with all of the lights. It plugs right into the computer’s USB port. Unfortunately, I haven’t built any yet, but assuming they work, they’ll be awesome. Right now, I’m just using a breadboard.


It’s modular! Basically, the designer specifies the types of lights he created as controllers. Then, he writes plugins that instantiate these controllers and modify them. So, you can specify complex environments very easily.

My implementation just controls the two lights I have so far. Right now, I just have some basic hue-cycling plugins, but I’m working on more complicated ones that will draw from inputs like music or the current time.

What’s Next

I have a little more work to do on the LED boards. I want to make the outputs screw terminals, clean them up, etc. I’m also starting to look into where I could potentially sell these boards as kits for people who want to make their own lights. I know a lot of people who are interested in using these boards in their own projects.

USB RS232 – RS485 Converter

So for ACRIS, I designed a board that would take serial over USB and convert it to RS485 to send to all of the instruments.

Unfortunately, as it turns out, I made a crapload of mistakes on that board and my first attempt at soldering it did not turn out so well. I fixed the mistakes on the board (the worst being that the USB connector was actually freaking backwards), but I then began thinking a little more carefully about what I was trying to do.

It occured to me that the best way to design a USB -> RS485 converter would be to make it an actual dongle, like a flash drive or wireless dongle. The result is 2 inches long by .6 inches wide and has spots for 2 RJ-45 ports. It also uses the TXDEN signal to determine whether to send or receive data instead of just always placing the RS485 chip in transmit mode.

I’ll be sending an array of these out for ordering soon. I have to replace a few parts from the other board I designed, but other than that, it’s roughly the same as the previous ports.

One of my friends, Marcel, is a fantastic mechanical engineer. Perhaps he’ll be able to give me some guidance on building enclosures for these boards.

And we’re (more or less) back…

Wow. My last post was in late July. I’m not really sure what happened in August, but this semester has been hitting me repeatedly with a bag of bricks. Every time I think that I can spend a few hours working on personal projects, it turns out that I just forgot about something else that I had to do. I thought senior year was supposed to be easy. 🙁

Anyways, this post is a general update on what’s been going on and where some of my projects are headed.

LED Controllers

I’m so sad that I’ve essentially left ACRIS untouched since the beginning of the semester. Also, I haven’t even come close to finishing documentation for it yet. SADNESS

‘sokay though because I’m finally getting back to working on it, even if I should be doing other things. I found a couple of bugs in the first boards that I made, but they should be fixed for the next revision. I’m hoping to start selling them as kits at some point, but I need to work out a few details before I’m ready to do that. In particular, the parts are expensive. I really wish I could make the board modular somehow so that you could add any number of LED controllers onto the board. Also, I’m tying the outputs of the LED driver together in groups of 3, but that may not be what a user wants. What’s the best solution for that? IDK yet.

To whet your appetite:

At any rate, I’m hoping the project will be good enough for Hackaday. I’ve been working hard on it, but I never really know if the work I do is good enough for others to find interesting.

Tor for Microcontrollers

For the computer security class I’m taking, I’ve decided on a kind of weird (and probably a bit stupid) final project: Tor for AVRs. The idea is that if you have a mesh network of devices, you may want one device to securely communicate with another without knowing who the source really is. To demonstrate this, I need an array of AVRs… I was hoping to get some funding, but it looks like I’ll need to buy everything myself. I’ll be documenting this over the next few weeks. (I also need an entertaining name.)


Two of the classes I’m taking this term are particularly interesting. 6.828 is an operating systems engineering class. It’s basically a lot of C, but I particularly like it because it balances classroom instruction with a lot of coding. The labs in the class have you implement core aspects of an exokernel-like operating system. The most entertaining part is that when you run into a bug, it’s usually because you implemented something wrong 3 labs ago. It makes for fun times.

Proficiency with gdb is pretty much essential. A while ago, a coworker pointed me to this article on how to pimp your gdb with a few features that allow you to see how your code is running.

Also, I’ve recently added cscope support to my vim configuration. My productivity has skyrocketed when coding in C (ctags is still useful for other languages).

6.858 is a computer security class. I’m also enjoying the labs in this class, which are approximately split evenly between teaching methods for attacking systems and defending them. The first lab, for example, taught a few buffer overflow attack techniques.

Other Stuff

I’ve updated my blogroll a bit. I also plan to recategorize a lot of my older posts to make searching and so forth easier.

ACRIS on Github

I’ve added a remote branch to Github so that you can track the latest progress of my development. Things are very experimental right now, but I’ve had success so far. I’m hoping to get the boards in by the second week of August. Note that I’ve made a mistake on the LED controller version that’s on my website (wrong crystal size) — I’ll upload a new version of it when I get a chance. Also, I made a mini (1.4″x0.88″) LED controller board that uses all surface mount components.

Anyways, the Github repo is located at

ACRIS LED Bootloader Ready!

The last major hurdle for the LED controller is finally done. I’ve finished designing a bootloader that allows you to program the device over the RS-485 network, thereby eliminating the difficulties I had originally experienced with in-circuit JTAG programming. I’ve also finished a Python library and application that makes working with the bootloader quite easy.

I just need to do one final verification of the LED controller boards and then I’ll order some. After that, it’s just a matter of assembly and writing some programs to control the colors of the system.

ACRIS — Automatically-Controlled Room Illumination System

I’ve been interested in lighting effects and visualization of sensory input for quite some time. LEDs are spectacular devices because they are so incredibly versatile. I’ve specifically become interested in RGB LEDs, which have 3 dies in one package, one for each color. Furthermore, I find the high power LEDs to be particularly amazing. I’ve done a lot of work with these LEDs, which can do 350mA per channel. They’re extraordinarily bright.

A year ago, I came up with the concept of ACRIS (Audio-Controlled Room Illumination System). The first design would use an FPGA for sound processing and wasn’t going to modular at all. However, I never had the time to work out the long development cycles associated with using FPGAs for large-scale projects.

Now, using what I learned from my design of the electronics for the Next House Party Lighting System, I’ve designed generic, modular LED controllers that are very easy to interface with. They can be controlled by a computer, an FPGA, a microcontroller, etc.

ACRIS has been reborn as “Automatically-Controlled Room Illumination System”. It will have sensory input from a variety of factors. I’m still trying to come up with creative ideas for styles of illumination, but I have the majority of the electronics ready.

Namely, I’ve designed the LED driver board and the communications board, which contain all of the electronics necessary to run the system.

These boards are extremely generic. I’m trying to make them such that people can use them for their own DIY projects — I want to take all of the tough technical problems out of the process so that people will have more time to explore their creativity and design interesting lights.

ACRIS – A Hardware-Based Audio Visualization Project

I’ve always found audio visualization to be pretty interesting — it combines the complex (hah, pun) mathematics of signal processing with the entertainment of watching cool effects. Many audio players have interesting audio visualizers built-in; others are available as addons. MilkDrop seems to be quite popular.

Funky patterns on a screen changing to music is cool, but for a while, I’ve wanted to create a more entertaining experience. Essentially, my idea has been to create a set of wall lamps powered by arrays of multicolored LEDs. A microprocessor would adjust the color and intensity of the lamps based on audio input.

From a high-level standpoint, this kind of system is not too complicated. A low-latency audio processor takes audio signals as an input, performs some frequency analysis on them, and generates PWM signals. These PWM signals are fed into LED arrays making up the wall lamps. As always, though, the devil’s in the details.

System Design

The final design will use an FPGA with some simple support hardware to do the audio processing. Overkill? Probably… A fast microcontroller is usually good enough for these kinds of things. But, I wanted to make this a hardware project. The FPGA I plan to use is a Spartan 3, available cheaply on this eval board.

To elaborate a bit, I’ll feed an audio signal into a high-frequency opamp, which will buffer the audio signal and send it to an 8-bit ADC, whose output is fed into the FPGA. The FPGA will take an FFT of the data and then, based on the color mixing algorithm I choose, will operate on the frequency data. Finally, after deciding the final desired color, the FPGA outputs PWM signals to the wall lamps, those internal circuitry amplifies and uses those signals to light up the desired color. I’m hoping for a total latency on the order of tens or hundreds of microseconds.

I’d like to put up three or four lamps. One will be on the left side of my room and another will be on the right. These two lamps will be controlled solely by their respective stereo components. The other lamps will be above my desk and will be controlled based on a combination of left and right audio data.

I was originally hoping to make the wall lamps interact wirelessly, but I don’t think that’ll be possible given the price of wireless modules. Also, there is a latency problem as well as a security issue involved with wireless.

Anyways, I’ve had a few ideas for the color mixing algorithm. One was to separate the frequency graph into three large chunks (e.g. “low” frequency, “medium,” and “high”) and then define some sort of color scale for each chunk. Next, for each chunk, the center of mass is determined and is used to locate a color on the chunk’s color scale. The relative intensities are compared and then a final color is mixed. This algorithm is actually very easy to implement. A friend of mine suggested another interesting algorithm (harder to implement, but definitely worth a try): split the frequency graph output from the FFT into octaves and then define the same color scale for each octave. Colors are mixed in proportion to their intensity. This guarantees that all equivalent pitches (across octaves) have the same color. You could also improve the algorithm a bit to make the lower octaves biased toward one color and the higher octaves biased toward another. There will be three multiplexers
to determine the FPGA input. The first will allow switching between 2 or 3 analog audio channels. The second can bypass the ADC and send digital data directly into the FPGA. The third will bypass the FPGA directly and allow some device (e.g. a microcontroller) to send in PWM signals to the LED arrays.

Finally, as a finishing touch to bring out the bass, I’d like to add blue backlighting to the wall lamps that lights up only to low frequency responses.

As for the LEDs to use, an array of Cree MC-Es would be spectacular, but pricey. Another option would be to use a bunch of cheaper chips from DealExtreme.

Current Status

Right now, I’ve ordered and AVR and supporting hardware in order to use this project I discovered as a starting point. Instead of outputting a graph to an LCD, though, I am going to begin testing simple color mixing algorithms with whatever LEDs I can find. Using a microcontroller will allow me to quickly test algorithms, although the latency may be noticeable. In the future, I’ll switch the function of that AVR so that it can take input from other sources and control the lighting system.

As I begin building stuff, I’ll start posting my notes and diagrams.