Travel Bugs are tags used for items that “hitchhike” between geocaches. They are attached to items that people find in a cache and are intended to be transported to the next cache that the finder visits. This is essentially an asynchronous ad-hoc routing protocol for objects. It would be interesting to describe a desired destination for the Travel Bug, thereby enlisting each finder as an attempt to get closer to the destination. This would a kind of warped version of how an electronic packet might travel in distance-vector routing.
For midterm, Christian Croft and I plan to extend on the Cube drawing interface from the pair gaming assignment. We intend to focus our energies on implementing WiPorts in the physical cube interface. In addition to adding WiFi, each side of the cube will now have an analog switch (most likely an FSR sensor), and sensory feedback (either vibration or sound) according to what is happening on screen. We hope to improve the actual fabrication of the cube by cutting plexiglas with the lasercutter at ITS. Eventually, we plan to expand beyond the 3D drawing task in the current processing applet and introduce some enhanced gaming and entertainment features.
The ITP program lobby display screen faces Waverly Street through a double-paned glass window. This setup is fine for showing off purely visual work, but doesn’t work for anything with an audio component. Sounds played behind the double-paned glass cannot be heard on the street, and the facility will not allow speakers to be placed on the outside of the building. Our solution is to reach passers-by via their mobile phones. When works with audio are shown on the screen, we will display a phone number to dial so that the public has a way to hear audio from the screen.
We initially considered using a SoundBug to transmit audio through the glass, but this does not work on windows with more than one layer of glass. We also considered using an iTrip type of FM transmitter, however it is uncommon for pedestrians in New York to carry a radio these days. The solution was to accept calls into a Voice Over Internet Protocol (VOIP) service so that the computer itself could receive a call from the mobile phone network. We chose a Skype setup because it allows for calls to be automatically answered and will work on Macintosh, Windows or Linux. Next we plugged the audio OUT from the server back into its audio IN jack. When a Skype call is answered, it transmits whatever is on the audio IN–in this case the sound that would otherwise be coming out of the computer’s speakers. Beta testing of this setup began today, and it seems to work great!
Continue reading ‘Mobile Phone as Audio Output for Public Display Screen’
