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!
You can find it on Github here!
If you want to make any plugins, fork it, make them, let me know, and I’ll merge them back into my branch.
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.