Preliminary Detailed Design
Table of Contents
Team Vision for Preliminary Detailed Design Phase
- During this phase our team planned to continue to benchmark similar noise cancelling systems. The goal of this phase was to break down the main system into its constituent subsystems. Another objective of this phase was to analyze these subsystems and propose basic experiments to prove or confirm the feasibility and functionality of these subsystems.
- At the end of this phase the team was able to propose new basic experiments to confirm feasibility of the subsystems (including: production of anti-noise, controlling multiple inputs - microphones and outputs - speakers with one central computing location, determining the parameters of a stationary sound source with the SPEA2). The team also proposed a bill of materials, developed detailed subsystem designs, and began exploring the input and output parameters of the SPEA2.
Prototyping, Engineering Analysis, Simulation
The preliminary design phase was driven by an engineering analysis. As our design was broken into more detailed pieces, and the preliminary setup had begun on both the code base and the materials had begun, more questions came up on how we should approach certain problems.
Problem: What is our programming solution? How do go about bringing our preliminary design into the real world?
Solution: Use an Object-Oriented approach in C# to design and represent each physical entity in the process. In our programming solution, we will be able to use an object oriented approach to the system design.
Problem: What does noise cancellation look like from a normal users perspective?
Solution: Sound from all sources come in the form of waves. Below is a sample taken from Gleason on the 4th floor just after announcements. The human hearing can range from 0Hz to 20kHz.
We can analyze sound by establishing an example waveform. Most waveforms in the workplace and other areas are far more complex than the waveform displayed below, but for the idea of simplicity we should stick to looking at this particular waveform.
We need to take in a signal as shown above. The signal ranges frequencies from 0Hz to 20kHz. The signal can be split into multiple frequencies using a Fast Fourier Transform. A Fast Fourier Transform (FFT) is a means of converting a function from the time domain into the frequency domain. In so doing we determine the discrete fourier transform and convert all the signal into its discrete factors.
We can then follow this up by manipulating each individual signal (typically bying doing a 180 degree phase shift) and then re-summing the signals together into an anti-signal.
Below the red graph demonstrates one of these waveforms (for example, a 7kHz signal) is shown by itself. We should be able to simply change the sign of the equation (or do a phase shift of pi) and reach an anti-signal.
We can then transform the signal by inverting it: either through flipping the sign or doing a phase shift.
There are multiple reasons that an ideal solution is extremely difficult to incorporate. First, even the best technology in microphones cannot 100% perfectly capture a sound in any normal environment. The second issue is that to produce a FFT fast enough for our project there will need to be a 'close enough' answer that will be imperfect. Thus, our anti-sound wouldn't even be able to completely nullify the signal because of the near real-time nature of this design. With the non-ideal circumstances, the noise floor should still be reached just fine. As a result, we may get a result that looks similar to this design here.
Our solution now needs to take into account that the speakers will be a distance X meters away from the listener and the sound source will be Y meters away from the listener. Both sound sources will be a different coordinate position away from one another. We are keeping the listener, speaker and sound sources on the same 'z plane' to ensure a simple model. As a result, the amplitude and phase may need to be altered.
Problem: Common laptop speakers have difficulty reaching frequencies below 1kHz. It was established earlier on in the project that cancelling noise above 1kHz is difficult without the use of a direct headphone solution.
Temporary Solution: Work with speakers that can handle lower than 1kHz frequencies temporarily. The reason why laptop speakers have a hard time keeping up at lower frequencies is due to their inability to produce high enough air pressure to produce the low frequencies. They are just not equipped with the right tools to perform this task and thus a different speaker solution is needed for these lower frequencies. How different speakers work with different air pressures is not something that can be manipulated in the scope of this project.
Feasibility: Prototyping, Analysis, Simulation
- For prototype design, estimated maximum required
- (5 microphones)*(44,100 samples/sec)*(64 kB/sample) = 14.1 GB/sec
- Assuming an average classroom size room and taking into account for the speed of sound, the actual memory required should be a considerable amount less than the estimated value.
Sound Frequency Cancelling:
- Designed for prototype system to cancel frequencies in the range of human hearing: ~ 20Hz -20kHz.
- Short duration, extreme (below ~100 Hz and greater than ~10,000 Hz) frequencies will be more challenging to cancel.
USB vs. Analog:
- USB (hardwiring the devices) will remove the need for a controller and will limit the amount of delay between receiving a signal and producing its corresponding anti-noise signal.
- With analog 3.5 mm connections, the computer still needs to have a sound card to read the input. Research showed distinct sound cards are needed to drive a single device.
- With USB devices, the controller is on board and there is no need for sound cards.
- There is not always the ability to drive multiple speakers from one controller, and therefore making the USB the preferred choice for interfacing between devices.
- Interfacing between several devices adds greater complexity
- In order to handle this greater complexity of data transmission and reception, a client and server software would need to be created - for current feasibility testing, this is outside the scope for the initial prototype.
- All feasibility testing will be completed with a signal computer which may require server grade hardware depending if the calculations are two complex for the limited machines.
Drawings, Schematics, Flow Charts, Simulations
Bill of Material (BOM)
|Quantity||Unit Price||Item||URL||Total Cost|
|1||6.99||USB Stereo Adapter||https://goo.gl/QzwCVo||6.99|
|1||13.99||USB Powered Speaker||https://goo.gl/XLbiS9||13.99|
- Verify Noise Reduction: Measure typical room dB level and compare to when system is active
- Frequency Range of Human Hearing: Start with ~100-1000 Hz as that is the most stable range of freq response for typical speakers. Work up from there. Works because that’s range of voices.
- Scalability: Design code so that amount of mics is single variable so that additional mics can easily be added. Test out how long it takes to add/subtract mics
- Frequency Response of Speakers: Can multiple speakers with poor bass response combine into a suitable speaker
- Decay of Noise through air (validate Stokes’ Law of Sound Attenuation)
- Test out all homebrew algorithms from flowchart
- Algo 1: Using known mic locations, run algo to see if it matches actual distances
- Algo 2: Using known mic and speaker freq responses, run algo and see if mic freq responses are correct
- Algo 3: Same as algo 2 but make sure speaker freq specs match actual.
Risks within the Preliminary Detailed Design
- Microphone Integration and Packaging of Data
- Need to make certain that the sound taken in by the microphone is the true sound
- Program needs to be able to understand and recognize the sound taken in by the microphones
- SPEA2/RWT Understanding
- Taking the Population Data, importing the information into the RWT and then be able to take the resulting information out of the algorithm
- In general, Cracking and Documenting the SPEA2
- Operation in Real Time and Consistent Program feedback
- Speaker and Microphone Feedback
- While the microphones do need to be listening in order to keep the process going, when the speakers are emitting the equal and opposite noise - the microphones need to not pick up the information that the speakers are emitting
- Correct Calculations
- Outside Noise Sources
- Three Dimensional Area to Silence
- Speaker Location
Plans for next phase
- Investigate links between subsystems to ensure units, formatting, etc are compatible with one another.
- Finalize custom algorithm samples
- Using finalized subsystem designs, generate class tables
- Finalize BOM with future development in mind