Researcher Computer Networks and Signal Processing
https//bizarrestarwarsmerch.tumblr.com is a collection of the bizarre Star Wars merchandise that started appearing after Disney bought the rights to the franchise. There are some other lists of bizarre merchandise, but other collections are old, not weird enough, incomplete or ad-ridden. I may not be the hero the internet needs, but I am the hero it deserves.
In 2016 I circumnavigated the globe, visiting friends and family across five continents. I used a digital recorder to make field recordings of the various interesting things I heard during my travels. This is a playlist of the highlights.
endless.horse was my project for the 2015 Stupid Shit No One Needs & Terrible Ideas Hackathon, and it was subsequently featured on the front page of Hacker News and BoingBoing. When the number of Top Level Domains greatly expanded in 2015, I knew that there were many stupid website waiting to be made. I found mine in endless.horse.
This thesis documents the design and implementation of a new anonymous communications protocol, and an analysis of an existing protocol. NCGAB, proposed by Sergeev in 2013, efficiently implements broadcast over unicast and requires no pre-existing infrastructure. We propose a second protocol, CHAP, which extends NCGAB and is designed to use wireless broadcast capabilities as well as wired links. We show anonymity for some information-theoretic measures under certain assumptions regarding adversaries and traffic independence. Numerical results show that for some networks NCGAB fully anonymizes up to 90% of messages, with the remaining 10% having strong anonymity properties. NCGAB also improves up to 30% upon the baseline anonymity provided by a network coded gossip protocol not optimized for anonymity. We compare CHAP to NCGAB and show that CHAP is at least as anonymous as NCGAB and also exhibits interesting hierarchical separability that allows multiple anonymity protocols to operate simultaneously in different domains.
One of my housemates has a cat named Errol. We have a small apartment now, but he used to live in MIT housing with us, in a five story brownstone with 30 other students. He had gotten used to that level of chaos, so nowadays he is a bit under-stimulated. We make efforts to play with him, but we are often out of the house. After thinking about what we could do to keep him entertained remotely, and discarding expensive ideas (like a roomba), I figured that an Arduino controlling laser pointer on top of a couple servos would be pretty cheap. After throwing in a webcam, it could even be controlled remotely. After searching around for a bit, I found out that other have thought of this before. There is an Instructables post on it, and it has even been commercialized. These both didn't really do what I wanted, though, so I decided to make my own version. For my cat laser, I decided to go a slightly less DIY route on the servos, instead opting for a $15 2-servo camera controller from eBay. This plus the laser and an Arduino was all I needed for the most basic prototype, which you can see in action here.
This is a silly little javascript game that Kyle Miller and I made one Sunday afternoon. Lasers shoot out of my eyes to destroy the targets (simple little colored squares), and a count is kept. It began with just the moving head animation, which was inspired by the set of images of my head at different angles that I had on the homepage of my old website. Basically everything is done using divs (as opposed to canvas).
Turn on the sound for silly homemade sound effects.
This was the final project for 6.267, a graduate class about heterogeneous networks. It was taught by Professor Vincent Chan, who does interesting research in optical networks among other things. I worked on this project with Dave Adams, a fellow lab mate of mine who also happened to be taking the class that term.
This is a design proposal for the link layer and media access control (MAC) mechanism of a seismic monitoring and warning network in California. This network consists of 100 monitoring stations, or sensors, distributed across the state, with one centralized base-station that all of the sensors report to. The network operates on the HF radio band, which enables communication over long distances due to ionosphere reflections. However, the propagation delay is quite high (20ms), as is the bit error rate (10^-2, after error correction). Additionally, there are occasional short drop outs lasting less than 20ms, as well as multi-hour stretches of bad channel conditions depending on ionosphere conditions. The network can operate up to 40 kbps, but if either a monitor or a base station have bad ionosphere conditions, then the rate is down to 4 kbps.
Under normal conditions, the sensors send hourly updates to the base station. Occasionally the base station will send out multi-megabit software updates. If an earthquake occurs, all the sensors that hear it need to send an emergency alert to the base station. The base station then selects a subset of the reporting stations to send a detailed report, which will contain measurements about the seismic activity that just occurred. The number selected will be about half of those that sent an emergency alert, and the earliest alerters are very likely to be selected for sending a detailed report.
The goals here are to create a system that maximizes efficiency under non-emergency situations, but to minimize latency while an earthquake is being reported. In other words, time-sensitive data is highly prioritized.
This was the first project for 6.267, a graduate class about heterogeneous networks. It was taught by Professor Vincent Chan, who does interesting research in optical networks among other things. I worked on this project with Dave Adams, a fellow lab mate of mine who also happened to be taking the class that term.
Wireless networks introduce many difficult challenges, and the increasing mobility of hosts only exacerbates these issues. Users want to be able to walk from place to place with continuous and automatic network connectivity. Most modern wireless networks have quite poor support for moving hosts, however. The connection must usually be re-established when the host finally becomes stationary. The problem is that by the time a moving host establishes a connection with an access point, they are moving out of range.
Wireless access points have a relatively stable topology in most buildings. This information can be used to figure out where a host is likely to go next so the access point can be ready to interact with the host seamlessly. Most currently deployed schemes do not take advantage of these properties. With this protocol we aim to change that, and create a system that can predict where a host will be so that continuous communication is possible as a host moves across the network.
This was my term project for 6.829, MIT's graduate computer networking class, which I took second semester senior year. We compared the performance of two wireless bit-rate selection algorithms and made improvements to one of them.
Bit-rate selection is the process of choosing which bit rate to send with over the wireless link. Unlike wired networks, it is very common for wireless networks to send at lower rate that the maximum the channel supports. This is because wireless channel conditions are rarely ideal due to factors such as fading and interference. The goal is to select a bit rate that achieves the highest throughput, and to keep that rate updated as channel conditions change.
We compare the performance SampleRate and Minstrel, two popular bit rate selection algorithms that have widespread real-world usage. We use a tracebased approach to avoid kernel programming and improve reproducibility and allow analysis. We test both algorithms in multiple real-world scenarios, including scenarios with mobile clients and noisy environments, to highlight differences between the two. We also introduce improvements to the Minstrel algorithm that allow for significant gains in throughput.
In 6.033, MIT's Computer Systems Engineering class, I wrote a design paper about a provenance tracking file system. Although a provenance tracking file system is not something I would use on my own system, I did think hard about the design and I am proud of the resulting paper.
In 6.005, MIT's Software Engineering class, we had two big group projects that were important components of the class. Our final project was designing a chat protocol, and then creating a server and a GUI client. I worked on a team with two other people.
Our protocol is simple and lightweight, inspired by IRC. Our server relies heavily on functional programming style, and our client uses the Model-View-Controller design pattern.
The house I lived in as an undergraduate had a bunch of Color Kinetics equipment lying around. Color Kinetics are a brand of color-changing LED lights. I decided to try and maximize showertime awesomeness by setting some up in our shower, as well as a couple of speakers.
The lights were connected to an ethernet-capable power supply, which let me control them from my computer. Then Kyle Miller made a web interface to control the various light displays in the house.
To keep the equipment out of a humid environment, I stored the light power supply and the speaker amp in the closet of the adjoining room, and then drilled a hole through the wall to route the cables through. Check out the end result in the pictures below.
The wires going through the wall:
I installed a separate volume knob because the amp was in another room (it had gotten annoying to run back and forth between rooms in a towel to adjust the volume).
The power supply and amp:
Off of the same power supply, there was also another set of lights illuminating my bed. The beautiful artwork you see is by Katherine Burdwood.
I also wrote a plugin to the Audacious media player to
control the lights I installed. Audacious has a pretty
nice (albeit somewhat undocumented) C API . I utilize
the Aubio library to extract onset and beat data from
music, and then fire light events to the beat of the
music.
The analysis of the onsets is
relatively simple; I made the changes more drastic when
the onsets are very close together, and there is
rudimentary syncopation detection. I had dreams of being
able to compile information about beat patterns, which
would have let me do cool things (e.g. extract the 20
most frequently occurring beat patterns and set off
specific events when they begin: a motif-based light
show!). My MIT classes started taking up a lot more
time, though, so the project petered out.
In high school I did a lot of work in my theater's sound booth. I realized that I really liked working with audio (part of the reason I study signal processing), so I got my own mini-studio setup: two JBL LSR2325P studio monitors, a Mackie Onyx 1220i firewire sound board, an M-Audio Oxygen 49 USB MIDI keyboard, and a custom-built desktop with an AMD Phenom processor and plenty of RAM. To keep costs down, I did't invest in a solid state drive, but it is a good idea to have disk write speeds as fast as possible.
Now that I had the hardware, I needed software. Most software (ProTools, Logic Studio, etc.) was designed to run on a Mac or Windows system...but I didn't really want to run either of those operating systems. Also, these tools are expensive for a student.
I did some Googling, and found out that there is a completely free and open source digital audio workstation called "Ardour". It was much more sophisticated than Audacity (not to disparage Audacity, it is designed to be a simple editor), supporting unlimited audio tracks and a nice way to plug into JACK.
I discovered that there is actually a wealth of audio software available on Linux. Here's a list of some of the stuff I use:
I realize that most of these are not nearly as polished as their professional counterparts, but some of them are actually quite sophisticated, and all of them are free! I also find it exciting to be on the "cutting edge"...a lot of the stuff I run is the latest development version, and it is exciting to participate in an active and growing project.
I followed a number of guides to get my system working the way I wanted, and I communicated personally with many of the authors. They were extremely friendly and helpful, and were often glad to provide additional help.
I didn't follow these guides exactly (for example, my system is built on an AMD64 kernel despite Audiodef's recommendations), but they were fantastic starting points. I now have a basic system up and running, and I look forward to putting some of my recordings/works on this site.
Copyright © 2009- Colleen Josephson · Template from Solucija