Table of Contents
|
Team Vision for System-Level Design Phase
What did your team plan to do during this phase?The goals for this phase included constructing a functional decomposition in order to determine if the functions of the project closely satisfy the functional requirements. Other various goals included obtaining benchmark information to determine how the team plans to quantitatively meet the engineering requirements. All information and functional brainstorming is used to determine the feasibility of the project along with developing concepts and eventually reaching a final concept solution.
What did your team actually accomplish during this phase?
The team was successfully able to narrow down a few different functional design concepts that would help experimentally test the engineering requirements and determine how the customer requirements can be achieved. The team also performed and purposed different feasibility analyses including: the output of traditional laptop speakers, the possibility of controlling multiple speakers and microphones from a single source laptop, and examining the different decibel sound levels when comparing ambient noise to a ‘cocktail’ party setting.
Functional Decomposition
The goals of this project are to reduce the overall noise of the work environment within the bandwidth of the average human hearing capabilities in real time with minimal adjustments from the user. The expected result is a functional prototype consisting of a specialized algorithm based on the SPEA2 that is able to operate on a typical laptop speaker and microphone in order to reduce the noise of the current environment. The resulting design needs to align with project goals and serve as a functional prototype for backers to demonstrate feasibility for a possible consumer product.Inputs and Source
1. Project objectives:
- Locating sound source by implementing the SPEA2
- Demonstrating the ability to locate sound source using multiple fixed locations of microphones and speakers
- Effectively reducing the noise by a specified decibel level outlined by the engineering requirements.
- Minimize delay between input sound signal and output of anti-noise.
2. Engineering Requirements:
- Implementing SPEA2 to determine sound source location
- System responds to frequencies ~20Hz-17KHz
- Program/function will use either Java or C# programming language
- System will be scalable regardless of node count (minimum 3 for concept design).
- Noise should effectively be reduced by 30 dB
3. Benchmarking Data
- Laptop Speaker Loudness Capabilities
- measure the output of one or several laptop speakers and determine if it is capable of cancelling the required amount of noise
- “Cocktail Party” Noise Level
- measure multiple work environments in order to obtain average sound level
- Room Reverberation Levels
- Record various noises in several different ‘quiet’ rooms and determine if any reverb levels of produced isolated noises.
- Research other noise cancellation systems and their effective noise reduction data and delay time. Ex. white noise, noise cancellation headphones, etc.
- Research other systems or programs that were successfully able to interface one computing system with multiple speakers and microphones.
Outputs and Destination
1. Main Functions (including sub-functions) of Cancelling Noise
- Detect Noise
- Read Both External and Laptop Mics
- Process Signal
- Central Processing location to collect all data and control system (turn system ON/OFF)
- Locate Sound Source
- Implement SPEA2 and triangulate microphone/speaker pairs
- Produce Anti-sound
- Use external speakers
2. Concepts Generated around functions
- Triangulate microphones/speaker pairs with ‘user located inside the triangulated region, along with the sound source.
- Triangulate microphone/speaker pairs with ‘user’ located inside triangulated region, with sound source located outside triangulated region.
Benchmarking
- Laptop Speaker Loudness Capabilities
- Using Sound Pressure Level (SPL) meter, measure the capabilities of one or several laptop speakers and compare to required amount of noise to be cancelled
- “Cocktail Party” Noise Levels
- Using SPL meter, measure several work environments to determine general sound levels and compare that to 30 dB reduction to verify engineering requirements
- Room Reverberation Levels
- In a (or several) quiet room(s), using a microphone record various sounds (ie. dropping a book, clapping, yelling, etc) and then using a Digital Audio Workspace (DAW) record (if any) reverb levels of produced, isolated noises.
- System Propagation Delay
- Measure individual components of system throughout design to minimize total system delay. Measure computation time of written code.
- Other Noise Canceling Systems
- Research other noise canceling products. Compare reduction in dB levels to engineering requirements of our system.
Concept Development
Detect Noise
Solution | Pros | Cons |
---|---|---|
Laptop Microphone | No need to purchase | Poor Quality |
Easier to control | Few specs given | |
External Microphone | Superior Quality | Expensive |
Specifications are known | Complex to control | |
Both | Better noise tracking | Very difficult to control |
Laptop specs are unknown | ||
Expensive |
Communication of Data
Solution | Pros | Cons |
---|---|---|
Hardwired | Easy to setup | Physical connections |
Easy to interface | ||
Minimal Delay | ||
Works with all computers | ||
Bluetooth | Wireless | Complex to steup |
Complex to interface | ||
Transmission delay | ||
Hardware dependant |
Produce Anti-sound
Solution | Pros | Cons |
---|---|---|
Laptop Speaker | No need to purchase | Poor Quality |
Easier to control | Few specs given | |
External Speaker | Superior Quality | Expensive |
Specifications are known | Complex to control | |
Both | Unknown | Very difficult to control |
Laptop specs are unknown | ||
Expensive | ||
Increased sound interference |
Feasibility: Prototyping, Analysis, Simulation
Overview
The current set of concepts use the idea that microphones and speakers are tied together in location. This constraint is tied to the customer contraint that the software should be implemented on non-dedicated hardware. This contraint is flexible if during the development, distance from speakers becomes an issue.The customer concept involves using an existing microphone/speaker pair as a location for cancellation. This concept allows for cancellation signals to be generated where required. The software implementation should not be limited to cancellation at the above locations as it may be be ideal to remove the tie between a device and a user.
The current designs are intended to be written in C#. This language was chosen over Java due to library support, development suite tools, and performance. These choices were made based on engineer experience. The main concern of performance favors C# in that the code is not run through a virtual machine. The Java Virtual Machine, JVM, does allow for better code portability but does not lend itself to performance. The primary IDE for C# is more feature complete than the competing Java IDE. C# was also selected due to team skills, the EE students lacked object oriented experience and had a base use of C. Due to inexperience C# was selected for its documentation and robust development suite.
The project has a long term goal of developing research in the field of distributed area noise cancellation. With this goal, each of the above concepts are intended to be tested. These tests intend to document a core piece of the customer concept. The customer concept contains a several key elements that are going to be tested, each test has been separated to a different concept. The final concept may be altered as tests are completed and data is recorded.
Key Elements
- Driving multiple speakers from a single computer
- Driving multiple microphones from a single computer
- Cancel a constant noise
- Cancel a variable noise source
- Triangulate the location of microphone/speaker pairs
- Triangulate the location of a noise source
- Communicate between a client and a server
- Cancel multiple noise sources
- Cancel a single noise source at multiple locations
Concepts
- Customer Concept
- Multiple Computers
- Single microphone/speaker per computer
- Networked machines
- Dedicated processing server
- Variable noise locations
- Unknown computer locations
- Concept 4
- 3 Computers
- Single microphone/speaker per computer
- Networked machines
- Dedicated processing server
- Fixed noise locations
- Known computer locations
- Concept 3
- 1 Computer
- Multiple microphones/speakers
- Variable noise location
- Unknown speaker/microphone locations
- Concept 2
- 1 Computer
- Multiple microphones/speakers
- Variable noise location
- Known speaker/microphone locations
- Concept 1
- 1 Computer
- Multiple microphones/speakers
- Fixed noise locations
- Known speaker/microphone locations
Morphological Chart and Concept Selection
Active Noise Cancellation | Different Ways to accomplish the function | |||
---|---|---|---|---|
Functions of the Active Noise Cancellation | Option 1 | Option 2 | Option 3 | |
Listen | Microphone (External) | Microphone (USB) | Microphone (Wireless) | |
Process | SPEA2 based phase and location calculation | |||
Emit | Speakers (External) | Speakers (USB) | Speakers (Wireless) |
Ideal Solution
A fully developed proof of concept with multiple microphones and speakers that relay to a central computer with the fully supported code and SPEA2 Algorithm. This code and supporting algorithm analyzes the noise and then sends the correct signal to create and equal but opposite noise that creates a level of silence in the office.
Alternate Solutions
The speakers and microphones could be attached through multiple ways including Bluetooth for starters. This wireless connection would compound the issue of connection however because cost would be increased immediately.
The supporting code could handle different information outside of the SPEA2 Algorithm and perform more work than anticipated.
The goal of complete silence could come at a cost of not being able to cancel all frequencies either which is a tough design component to take a look at.
Code Variations:
- Code Analyzes the Noise and then dumps that information into the SPEA2 Algorithm
- The Code puts the Noise into sections based on frequency, phase, or amplitude and delivers the packets into the SPEA2. The Algorithm then determines the best course of action based on the delivery that the code gave it.
Failures and Backup Ideas
Areas for failure: Computer can’t handle the information and various inputs Way to Compensate: Figure it out- this is a main tenant of the project
Area of Failure: Anti Noise cannot keep up with real time analysis Way to Compensate: Have the code emit a ‘base’ noise to help cancel any general noise in the area.
Concept Selection
Systems Architecture
Materials
- X amount of Microphones (Inputs)
- Adapter Type System for the Microphones and Speakers (Inputs)
- Central Computer (Processing)
- Code (Which is all unpurchasable) (Processing)
- X amount of Speakers (Outputs)
Energy
- Power Source for the Computer
Information
- Noise through the Microphones (Inputs)
- Equal but opposite noise through the Speakers (Outputs)
Interfacing
First and Foremost: The computer needs to be able recognize the number of speakers and microphones that we hook up to the computer. The information that comes in from the microphone must be utilized and broken down as quickly as possible in order for SPEA2 to have a chance to pick the best antinoise to emit in real time. The sound that comes out of the speaker needs to not be picked up by the microphone and thus forcing the process to happen again.
Loop
-
Subsystem 1:
- Sound goes into the Microphone
-
Subsystem 2:
- Code (along with the SPEA2) realizes what the noise is
-
Subsystem 3:
- The equal but opposite noise goes out of the Speaker
The overall flow of the system falls within Subsystem 2 and creates the arch of the project. Subsystems 1 and 3 are the limbs of the project and have a smaller priority to the team throughout this process.
The research of the project and the most amount of time will build into the supporting code and SPEA2.
Risk Assessment
- Differences in hardware yield unpredictable differences in levels
- Unsure of how difficult triangulating a sound wave is
- Speaker quality prohibitively low
- Propagation delay too large for noise-cancellation
- Sonically isolated workspace required
- Group Cohesion
- Unforeseen Acoustic anomalies due to irregularities in room shape (think the ceiling of MSD room)
- Positive Feedback generated from speaker->microphone can cause negative byproducts
- Difficulty configuring system to accept multiple independent microphones
Plans for next phase
- Draft Detailed design for each subsystem
- Similar to functional decomposition
- Determine most-critical subsystem and begin Small-scale testing
- Create a Bill of Materials for each subsystem as well as a master BOM
- Identify time-sinks
- Large conceptual hurdle
- Experiment with SPEA2
Home | Planning & Execution | Imagine RIT
Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design
Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation