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.
Okay, so I have a ton of multimeters — I think around 5. I’m not really sure why; I think almost all of them I’ve gotten for free except for my favorite one, a Sinometer VA18B, which has a ton of functions and can also send data via USB.
But, I left a battery in it and the terminals got so corroded that they were destroyed. So I thought I could quickly solder a new connector to the board.
Rule #1 of electronics: DO. NOT. TAKE. SHORTCUTS.
I didn’t want to take the board out of the housing as shown above, so I thought I could just desolder the existing wires and feed the new ones in. I ended up lifting the pads, making those spots that I was supposed to solder completely useless. Furthermore, I accidentally had my iron temperature set too high, so I was melting a lot of the insulation (the high temperature also caused the pads to lift).
So, I fixed the problem by basically tacking the wires onto the sides of components that were electrically close to the original holes. Mechanically, this is a very bad idea; the connections are very brittle. Take a look at this mess:
And to top it off, the replacement 9V connector I had was too big for the plastic slot, so the battery cover didn’t fit on very well at all. Ugh.
So, morals of the story:
Don’t leave dead batteries in your devices.
If you’re going to do rework on a board, keep the iron temperature as low as possible.
Take the time to undo the extra few screws to have better access to the board. Otherwise, it’ll take you more time in the end and you’ll end up with a worse result.
On the plus side, my multimeter does in fact work again, so I’m happy about that.
So I was digging through some of my old electronics and I came across a device I bought a while ago but never really played around with. It’s a blue DPSS laser that I bought for practically nothing on eBay (I think the seller didn’t quite know what he was selling — they’re typically expensive). It’s not very powerful, but it’s certainly an interesting device.
It seems to have been ripped out of some old lab equipment, as there are lots of clipped connections. Furthermore, the construction is really interesting. There was a lot of reworking of standard components. For example, this DB-9 connector was modified to have two extra lines come out of the back.
I fired it up. It had a 5 second delay before it turned on (I believe this is supposed to be a standard safety feature according to government regulations).
I also tested it out on my laser power meter. I’m not really sure how accurate this meter is because I’ve had problems with it in the past, but according to it, the laser is outputting around 5mW stably.
In an effort to make organizing my music collection suck less, I wrote a script to automate the process of converting my FLAC files to MP3s for when I want to listen to them with my MP3 player.
Previously, I had no way to do this in an automated way. My music collection changes rapidly, so I needed a way to convert FLACs that haven’t yet been converted (or have changed since the last conversion) to MP3s. The first step of this process is to decode the FLAC and then pipe that to an MP3 encoder.
Next, I had to extract as much tag information as I could out of the FLAC and convert it into ID3 tags. Finally, if there are image files in the directory containing the FLACs, the script automatically embeds those images into the MP3 file (and tries to determine what type of image they are).
It also has a configurable number of worker threads, so you can process the files in parallel. It keeps a database of hashed files in ~/.flacsync/db, so when you re-run it, it will only retranscode new or changed FLAC files.
You can find it here. It uses some Unix commands like find. It requires Python 2, Mutagen, FLAC, and LAME.
It’s Christmas break now, but since I basically can’t get off of my semester sleep schedule (i.e. no sleep), I’m designing random crap.
Here’s a simple little framework I built over the past two days. I love my Novation Launchpad controller. I’m working on a controller mapping for Mixxx that turns it into a useful sampler. So far, so good, but I’ve got some more work to do before it’s usable to other people and not just me.
But when I’m not DJing, it just sits there on my desk. A while back, I wrote a simple CPU meter using PyGame’s MIDI support. It was cute, but rather useless. So, over the past few days, I wrote a framework that would let me create applications for the controller. I’ve created a clock and a little drawing app so far. I want to add a CPU meter, enhance the clock, and possibly make a Game of Life or something. The possibilities abound!
Sadly, my final projects this year weren’t too successful, but I’m posting one of them anyways: scln. For 6.858, one of MIT’s two security classes, I decided to work on a hardware-based security project. Specifically, I was interested in how onion routing could be applied to mesh networks. Given the relatively small time window, I didn’t have a chance to work on some of the cooler problems of mesh networking, but I developed a sort of basic framework for my idea. Although the i2c started doing weird stuff, I’d like to continue the project at some point (maybe I’ll make a framework board so that I can plug in Atmega168s).
What if, in some futuristic world, you walked into a room that was filled with sensors and you used your phone (or whatever they have in the future) to interact with all those sensors. But, you don’t want other people to know what sensors you’re using and you don’t want malicious sensors to collect data about you. Onion routing would be a good solution to this problem. Just as Tor protects your anonymity by bouncing your network requests around a bunch of servers, wrapping them in a layer of encryption with each hop, I wanted something that would let me do the same for something like microcontrollers. So, I built scln (“scallion”), a demo framework for onion routing on Atmel AVR chips.
It’s kind of a stupid demo because the point of onion routing is that you shouldn’t be able to see every single node on the network. Right now, all of the nodes in my demo talk to each other over an i2c bus. But, once the firmware framework is done, it’s easy to switch the communication to wireless or something. The model of mesh networks is much more dense than the model that Tor expects, so there’s probably some interesting research about the probability of anonymity that lies there.
This might be cute to demo when I design a sensor network for my room. I’m looking into doing some interesting room automation (probably in the spring) that involves a lot of automatic gesture recognition to perform tasks.
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.
Communication
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.
Software
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.
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.
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.)
Classes
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.
