P17347: Active Noise Cancellation
/public/

Systems Design

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.
Functional Decomposition

Functional Decomposition

Inputs and Source

1. Project objectives:

2. Engineering Requirements:

3. Benchmarking Data

Outputs and Destination

1. Main Functions (including sub-functions) of Cancelling Noise

2. Concepts Generated around functions

Benchmarking

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

  1. Driving multiple speakers from a single computer
  2. Driving multiple microphones from a single computer
  3. Cancel a constant noise
  4. Cancel a variable noise source
  5. Triangulate the location of microphone/speaker pairs
  6. Triangulate the location of a noise source
  7. Communicate between a client and a server
  8. Cancel multiple noise sources
  9. Cancel a single noise source at multiple locations

Concepts

Customer Concept

Customer Concept

  1. Customer Concept
    • Multiple Computers
    • Single microphone/speaker per computer
    • Networked machines
    • Dedicated processing server
    • Variable noise locations
    • Unknown computer locations
  1. Concept 4
    • 3 Computers
    • Single microphone/speaker per computer
    • Networked machines
    • Dedicated processing server
    • Fixed noise locations
    • Known computer locations
  1. Concept 3
    • 1 Computer
    • Multiple microphones/speakers
    • Variable noise location
    • Unknown speaker/microphone locations
  1. Concept 2
    • 1 Computer
    • Multiple microphones/speakers
    • Variable noise location
    • Known speaker/microphone locations
Concept 1

Concept 1

  1. 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:

  1. Code Analyzes the Noise and then dumps that information into the SPEA2 Algorithm
  2. 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

Concept Selection

Concept Selection

Systems Architecture

Materials

  1. X amount of Microphones (Inputs)
  2. Adapter Type System for the Microphones and Speakers (Inputs)
  3. Central Computer (Processing)
  4. Code (Which is all unpurchasable) (Processing)
  5. X amount of Speakers (Outputs)

Energy

Information

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

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

Plans for next phase

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