And I’m back! I’m determined to make up for not posting at all in the last month by being incredibly prolific in the next. I expect this to last for maybe one post after this one. But, hey – a guy can dream, right?
I should also warn people at the beginning that this is a long post. I wrote it to show people the way that I chose to tackle an electronics problem that was presented to me. It’s not something that I learned directly from any class, and I don’t have any clever terms to describe how I approach things. But it still shows something that I’ve learned from here, because before I got to MIT, I never would have been able to make it all the way through a project like this. Those of you that know basic electronics will find parts of it boring, and those of you that don’t will find parts of it inaccessible. You should read this anyway, because it’s just a cool project.
In my advising seminar last year (6.070 – it’s a great class – I highly recommend it, not just as an advising seminar), the instructor said (and I’m paraphrasing here) that “all of electronics can be divided into blinky lights, funny sounds, and weird smells.” I’m not sure why the smells were included though – we usually try to avoid those.
I’m a little disappointed that nobody has asked me about the breadboard I’m working with in my banner photo, because that actually happens to be a prototype for the project I want to talk about. It falls into the blinky lights division.
My friend Chris ’09 and I rented a Zipcar for a day at the beginning of the summer, because he was helping me move into my summer room at EC, and he also needed to run to Target, Costco, and a few other places. And once you have a Zipcar for more than 4 or 5 hours, it becomes cheaper to get it for the whole day, so we threw in a trip to IKEA just for good measure.
While we were there, we discovered these awesome glass shelves with fluorescent lights on the inside. They were called NIANs, in IKEA’s typical we’re-going-to-pretend-to-be-exoticly-Swedish-while-still-using-words-that-sound-like-English fashion. They were also on clearance, and thus marked down from $70 to $10. Now, granted, it is IKEA, so it’s hard to tell whether it was originally $70, but regardless, at $10, that was an awesome deal, so we bought two of them each. They look something like this:
So we’re two EE-inclined guys, and we look at these lit shelves, and we come to the natural conclusion that the only possible thing to do with them is to replace the fluorescent bulb with RGB LEDs, and then make that computer controlled.
And because Chris was a lighting techie in high school, he suggests that we should make both ends communicate using DMX512, a standard protocol for communicating between stage lighting devices.
So…I have a project. Well, more of a problem (problem as in problem set, not personal problem). And the way that I solve problems like that is by breaking it down into a series of simpler problems.
But before I do that, I’d like to give a quick preview of the finished project, or at least the project as it is now. We don’t have the LEDs in shelves yet, but we do have a demo board that drives one LED:
Ok. Back to the design steps. The first step for me is figuring out what the signal path is. I’ve already established that I’m using DMX to drive RGB LEDs, so it looks something like this:
Ok. The next step is to figure out exactly what’s coming in and exactly what needs to go out. On the one end, DMX travels on top of a protocol RS-485. That’s a protocol with 2 wires, and the signal is either a 1 or a 0 based on which of the two wires has a higher voltage than the other (called a differential signal).
On the other end, the LEDs will be powered with a PWM signal. PWM is a way of varying a signal from completely on to completely off. Since the red, green, and blue components of the LED should each have a variable brightness, we can use PWM to change it. Basically, you turn the output on and off really quickly, and the longer it’s “on,” the brighter the LED seems, until it’s always on, which is full brightness. For those of you who are math inclined, the brightness level that our eye perceives is the average voltage over time. Here’s a photo showing what the signal looks like when it’s 1/3 of the full brightness:
Just for comparison, here’s another signal that is 2/3 of full brightness:
Ok. So we know what signals we’re dealing with now. Let’s go ahead and summarize again:
Now that the problem is pretty well defined, I try to start from each side and work my way inwards until I have a series of processing “blocks” that I know I can implement individually.
For example, the two wires in the RS-485 (the protocol that DMX uses) signal can as high as +12V or as low as -7V, but most of the chips that I work with operate with signals that are +5V for a “1” and 0V for a “0” (These are known as “TTL logic levels”). Feeding something with the levels of RS-485 will almost immediately fry the chips, so I need to convert those levels to TTL logic levels.
Now, it just so happens that I know of a component that can take in TTL level DMX signals and convert those to PWMs: a microcontroller (often abbreviated μC – remember that μ is the Metric abbreviation for micro). A microcontroller is sort of like a miniature computer: you can write programs for it (usually in C), download them onto the chip, and either read inputs from the pins or make the pins high or low. Their processing power is roughly equivalent (or maybe slightly better) than the earliest computer that used to take up whole rooms. Since I’ve turned the problem into TTL signals coming in, and TTL signals going out, a microcontroller can probably take the place of that void of “Processing.”
So, the final flowchart looks sort of like this:
And that’s the signal path. But that’s a whole lot to digest for one post, so I think I’m going to stop there, and deal with the questions that I’m sure people have (because I’m terrible at explaining these sorts of things). Sometime soon I’ll do another post about how you go from that flowchart to a circuit, and then to an actual working PCB, and also deal with some of the problems I had – because it’s never as simple as the flowchart makes it look!