Concept
Motivation
Competition
Tech Specs
Architecture
Requirements
Use Cases
Risks
Time Lapse
Testing
Presentations
Videos
Pictures
18-549 Home

TEAM 10: Seeing Sound!
Spring 2011

MEMBERS

PROJECT CONCEPT

Our project will create an entire light show on the spot based on any sound input. The prototype will take in any sound form, from a song to a person talking, and use LEDs to make a matching light show.

MOTIVATION

iTunes and other music players make visual shows to go along with songs, but these players only use songs, and they have to look ahead in the song due to a delay from the song to the visualization. Our prototype will be able to create a light show from any sound in real time.

COMPETITIVE ANALYSIS

iTunes:

not real time
only works with songs

Color Organ:

only does amplitude beat detection
no intelligence
only one color

Christmas tree light programmer:

all done by user
done before hand
not in real time

TECHNICAL SPECIFICATIONS

Hardware:

Software:

Audio Processing Code
DMX LED Control Code
Main Code

Protocols:

DMX-512

ARCHITECTURE

microphone and iPod connect to audio shield via analog audio
audio shield outputs digital signal to arduino and analog signal to audio splitter
one line of analog audio splitter output goes to speakers
one line goes back to arduino's analog input
arduino outputs serial to DMX-512 shield
DMX-512 shield controls LEDs via DMX-512 protocol
click to view diagram

REQUIREMENTS

Functional Requirements:

takes in sound from ipod or microphone
determines what is being played (music, voice, ect)
extracts beat if listening to song
displays color corresponding to tone if listening to voice
creates light show around beat if listening to normal song

Non-Functional Requirements:

real time response to song
super awesome light show
fast recognition of input

USE CASES

Setup:

Set arduino pins in software

Reset:

Reset button
Monitor songs for dead air, perform reset after every song

Reliability:

Microphone can break, then we use iPod
iPhone can break, then we use microphone

Sound input:

through microphone
through iPod

Also see our Sequence Diagram

RISKS & MITIGATION STRATEGIES

Risk	Mitigation
2 shields need the same pin on Arduino	Jump the shields to other Arduino pins, make changes to pins used in software
Audio signal being diminished by audio splitter	Add amplifier in audio splitter
Microphone breaks	Use iPod for audio input
Speakers not being loud enough for demo	Use headphones
Microphone picking up background noise during demo	Use iPod
LEDs are not bright enough during demo	Turn off the lights in Rangos :P
Can’t get lighting DMX protocol working	Build our own LED matrix
DMX shield doesn't work	Build our own DMX shield

TIME LAPSE

To be completed.

TESTING

Response Time:

Why it matters:
This test is crucial to the functionality of our product because if the response to the beat is too slow, the lights will not be changing along with the beat in real time, and this will make the product not visually pleasing to the user.
How will we run it:
We will put a time stamp after a beat is detected, and a time stamp after the lights change in reaction to the beat, and in this way we can look at the differeneces in time stamp values and determine if the change in time is sufficiently small.

Setup Function Time:

Why it matters:
This test will determine the time the program takes to run the setup code. This is essentially how long from when the user turns on the system to when the LEDs start reacting to the sound.
How will we run it:
We will put a time stamp when the Atmel turns on, and also once the setup code is finished running and then we will compare the times.

Beat Speed:

Why it matters:
This test determines how quickly the LED display can process one full command sent via DMX-512. Once we have performed this test, we will know how rapidly we can send separate commands to the LED display and have it still display a light combination for every command. With this information we will know how fast we can send messages to the display, and thus how fast we can make the beat be.
How will we run it:
We will continuously call our function advance, which sends one full command to the LED display. Each command will be for the LED display to change to a very distinct color, for example: red, green, blue, red, green, blue. We will call advance faster and faster repeatedly until we observe a break down in the LED display, that is to say, we observe the display miss a color because the messages are being sent too fast. We will also write test code which puts a time stamp after every call to advance.