Thursday, August 20, 2020

Blinky Lights (Part I)

Blinky Lights (Part I) And Im back! Im 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. Its not something that I learned directly from any class, and I dont have any clever terms to describe how I approach things. But it still shows something that Ive 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 dont will find parts of it inaccessible. You should read this anyway, because its just a cool project. In my advising seminar last year (6.070 its a great class I highly recommend it, not just as an advising seminar), the instructor said (and Im paraphrasing here) that all of electronics can be divided into blinky lights, funny sounds, and weird smells. Im not sure why the smells were included though we usually try to avoid those. Im a little disappointed that nobody has asked me about the breadboard Im 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 IKEAs typical were-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 its 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 were 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. SoI 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, Id like to give a quick preview of the finished project, or at least the project as it is now. We dont 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. Ive already established that Im using DMX to drive RGB LEDs, so it looks something like this: Ok. The next step is to figure out exactly whats coming in and exactly what needs to go out. On the one end, DMX travels on top of a protocol RS-485. Thats 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 its on, the brighter the LED seems, until its 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. Heres a photo showing what the signal looks like when its 1/3 of the full brightness: [1] Just for comparison, heres another signal that is 2/3 of full brightness: Ok. So we know what signals were dealing with now. Lets 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 Ive 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 thats the signal path. But thats a whole lot to digest for one post, so I think Im going to stop there, and deal with the questions that Im sure people have (because Im terrible at explaining these sorts of things). Sometime soon Ill 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 its never as simple as the flowchart makes it look! [1] (This photo was adapted from the Wikipedia article on PWM, and so I am obliged to release it under the GFDL. Therefore, I also provide the source code used to generate the images 1 and 2)

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.