!blog - corey menscher

On Aspen Mountain, there area a number of “shrines” dedicated to fallen musicians…Elvis Presley, Jerry Garcia, John Denver, and even Liberachi. (view a panorama here.) The shrines are not well known or clearly marked. Usually a local has to show you the location, unless you sumble upon one while skiing through the trees. The shrines consist of memorabilia to the musician as well as a quiet place to sit and contemplate the musician’s life. The Jerry Garcia shrine is one of my favorite places to take a break on the mountain, and I always wanted to leave something behind. Instead of leaving a photo, ticket stub, or some other type of physical object, I decided that I would leave the actual MUSIC. Thus, the jerryPlayer was born!

jerryPlayer is a crank-powered audio amplifier. The original intention was to include a 1.5V mp3 player as well to create a self-sustained solution, but I had many problems hacking an existing MP3 player to work, which I’ll discussin a moment. The player is powered by a hand-cranked dynamo that can generate a max 12V at 500mA (short circuit current). The energy is stored in a 1F 11V capacitor. Here’s the energy data:

Measured Open Circuit Voltage (V): 12V
Measured Short Circuit Current (mA): 500mA
Target Capacitor Capacitance: 1F
Target Capacitor Charged Voltage (V): 11V
Target Capacitor Total Energy (Joules): 72J
Time to Charge (seconds): 63 seconds
Observed Power (Watts): 1.142W

The dynamo was taken from a LED bicycle light and hacked for my purposes. The unit came with a small power conditioning board that included a bridge rectifier chip (to allow the crank to be turned in either direction) as well as a capacitor to smooth the current. This was then connected to an LM386 amplifier, which needs a minimum of 6V. This amplifier is a simple one, but provides a good amount of power for the few feet of space I want to fill. The output will eventually be connected to a waterproof speaker to sit outside the housing, but for now it’s conneced to a 3″ speaker. When fully charged, the amplifier provides a decent audio signal for about three and a half minutes until it cuts out. This is actually better than I expected, and will provide a nice “snippet” of music for the shrine…encouraging people to hear a small portion and then move on. (I don’t want people to necessarily hang out for an extended period…although they could keep the player going with a few turns of the crank every few seconds.)

The amplifier’s input was connected to an iPod Shuffle to provide audio for the presentation, but I intend to use the the capacitor to power a 1.5V or 3.3V mp3 player in the final version. This will presumably reduce the amount of playback time, but from my tests it should only reduce it by a minute or so. I rendered four Coby 128mb mp3 players I bought at a Super Value store inoperable in my tests. They worked for a short while, but eventually died. I think this may be due to excessive current, although they are extremely low quality players and could just be very touchy about the condition of the power they are given. (I was using an LM317 variable voltage regulator, which supposedly provides relatively “dirty” current.) They would not have been a good solution anyway because their interaction requires that a user hold down a play button to power the device, and then hit the play button again to start playing. This could have been achieved though an external momentary switch, but I would prefer the player to begin playing when it is powered, so I will probably be using the Sakura DIY mp3 player for the final product.

For our “sensor” assignment, we were required to either record sensor readings to a web-based database or we could read information from a web service and represent it in a physical computing object. My partner Estee Wah and I decided to do the latter by grabbing traffic “incident” information for NYC and representing the current status in a unique way. We made a poster that depicts a road running to the horizon, with a cityscape in the distance.

Each of the four road lines are three dimensional translucent paper with a white LED behind them. The LEDs are then flashed in sequence to simulate movement (via an Arduino). As the number of traffic incidents increases, the delay between the LEDs flashing increases, slowing the perceived movement…as if one is in slow traffic.

Roady is programmed by grabbing a single <incident> tag from a PHP script that gathers XML traffic data via a customized RSS fee from Yahoo. Each <litem> node that Yahoo returns is one incident, so we simply count the number of items to get our traffic scaling factor.

Our first XPort assignment was to create a physical client for a networked Pong game. Anything would work as long as you could make the virtual paddle move left and right. My idea was to use a urinal, to allow players to urinate on two sensors to move left or right. (Yes it’s been done before.) I found a kids “training” urinal, which made for an easy-to–hack controller. My original intention was to use force-sensitive resistors (FSR’s) to trigger left/right movement, and they worked well in testing. However, I was unable to complete a working controller. Here’s what I learned:

• FSR’s are extremely fragile (I broke four and ran out of replacements)
• You can’t use the terminal “screen” command to listen in on serial communication between an Arduino and an XPort. If you do, the commands will never be received by the XPort!
• Vinyl tape stuck to plastic is not particularly watertight.