Posted on

Sarah’s Status Report for Saturday, Apr. 11

This week, we presented our midpoint demo. The demo went well with the visualization of a sound source in real-time. I also worked on writing the existing code into python. Since we found that the logfiles we were working with possibly had errors, I didn’t move on to the localization of sound source since making sure the existing processing worked was important. As I have received new logfiles for simulation, I believe the results will be better shown compared to last time.

Next week, I look forward to doing some testing with the logfiles to see if the output looks as we assumed. If there is time, I will be working on visualizing the sound source.

Posted on

Ryan’s Status Report for Saturday, Apr. 11

I’m waiting for the 96 microphones to be assembled. Once all of them are functional, I’m going to calibrate them by having John capture their output with a sound source of three tones at 2563Hz, 8667Hz, and 12597Hz.  These three frequencies we were observed from the recording of the air leak, so we will focus on these.

The sound will be played through a bluetooth speaker approximately 8-10ft away from the microphone array to minimize the variations in distances between the microphone and the sound source. If the speaker were much closer, the angle between the microphone array and the speaker will have a larger variance, as well as the distance between the mic and the speaker, since the microphone array is flat, not curved.

In the microphone’s datasheet, it lists the maximum sensitivity variation to be +/- 1dB, so they should be pretty close to each other.

The most basic calibration will involve taking the average of the three tones’s output level and simply adding or subtracting an offset to compensate for the sensitivity of the microphone.

If we find significant differences in sensitivity from one microphone to the next depending on the frequency, we will have to generate an equalization factor that is dependent on frequency, such as in a graphic EQ.

Next week:

Get the microphone array assembled and perform the calibration procedure.

 

Posted on

Sarah’s Status Report for Saturday, Apr. 4

This week, I mainly worked on time-domain delay and sum beamforming. I was able to make the simulation output. I received a 5khz and 10khz log files from John and processed for 96 channels, 8 by 12 array and 1-inch spacing parameters. The output is shown below.

However, I realized later that the logfiles are actual data from just 2 microphones. After adjusting to the correct parameters, the resulting output was below which didn’t seem to match out the assumption that there should be a single spike at 5khz. Major problems and problem fixes can be found in John’s Status report.

For next week, I will focus on writing a visualization for a heat map for the data.

Posted on

Ryan’s Status Report for Saturday, Apr. 4

This week I continued my work on synthesizing sounds of air leaks. I used a recording of a real air leak, performed an FFT on it, identified the peak frequencies in the audio, and created various variants of it.

As mentioned in last week’s update, the three peeks are at the following frequencies and amplitudes:

2563Hz: -24dB

8667Hz: -18dB

13597Hz: -17dB

 

I created waveforms of pure sine tone at 2563, 8667, and 13597Hz in three separate WAV files.

If all goes well, the phased array should be able to detect and physically locate the first two tones. The third tone’s wavelength is shorter than the distance between each microphones in the array, so it would be aliased. This is outside our frequency specification range, so the device should filter it out to prevent aliasing artifacts from appearing.

 

Next, I generated a Gaussian-distributed noise source centered at  approximately 2563, 8667, and 13597Hz in three separate WAV files.

They have the following frequency distributions:

They sound like this, in the order of increasing frequency:

The noise floor isn’t audibly low, and this is intentionally done to best match real world environments. If all goes well, the system should be able to detect and locate the first two tones even with the high noise floor.

Further work:

Reflow the 96 microphones and auxiliary components into the PCB and hook them up to the FPGA.

Test the system with the synthesized frequencies.

Posted on

Team Status Update for Saturday, Apr. 4

This week significant progress made in all areas of the project, including the hardware/FPGA component catching back up to the planned timeline.

To prepare for the midpoint demo on Monday, all group members have been working on getting some part of their portion of the project to the point where it can be demonstrated.  John has a working pipeline to get microphone data through the FPGA and into logfiles, Sarah has code working to read logfiles and do some basic processing, and Ryan has developed math and code that works with Sarahs to recover the original audio.

While at this point the functionality only covers basic direction-finding, this bodes well for the overall functionality of the project once we have more elements and therefore higher gain, directionality, and the ability to sweep in two dimensions.  The images below show basic direction-finding, with sources near 15 degrees from the element axis (due to the size of the emitter, placing it at 0 was impossible), and near 90 degrees to the elements.  The white line plots amplitude over angle, and so should peak around the direction of the source, which it does:

~15 degrees:

~90 degrees:

This coming week should see significant progress in the hardware, as we now have all materials required, continued refinement of the software, as most of the major components are now in place.

Posted on

Jonathan’s Status Report for Saturday, Apr. 4

This week I mainly worked on updating the FPGA firmware and computer network driver.  Boards arrived yesterday, but I haven’t had time to begin populating them.

Last week, the final components of the network driver for the FPGA were completed, this week I was able to get microphone data from a pair of microphones back from it, do very basic processing, and read it into a logfile.  This seemed to work relatively well:

source aligned at 90 degrees to the pair of elements (white line peaks near 90 degrees, as it should)

source aligned at 0 degrees to the pair of elements (white line has a minimum near 90 degrees, again as it should)

However, these early tests did not reveal a problem in the network driver.  Initially, the only data transmitted was the PDM signal, which varies essentially randomly over time, so as long as some data is getting through, so it is very difficult to see any problems in the data without processing it first.  Several days later when testing some of the processing algorithms (see team and Sarahs updates), it quickly became apparent that something in the pipeline was not working.  After checking that the code for reading logfiles worked, I tried graphing an FFT of the audio signal from one microphone.  It should have had a single,  very strong peak at 5KHz, but instead, had peaks and noise all over the spectrum:

I eventually replaced some of the unused microphone data channels with timestamps, and tracked the problem down to the network driver dropping almost 40% of the packets.  While Wireshark verified that the computer was able to receive them just fine, there was some problem in the java network libraries I had been using.  I’ve started working on a driver written in C using the standard network libraries, but haven’t had time to complete it yet.

Part of the solution may be to decrease the frequency of packets by increasing their size.  While the ethernet standard essentially arbitrarily limits the size of packets to be under 1500 bytes, most network hardware also supports “jumbo frames” of up to 9000 bytes.  According  to this : https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=2ahUKEwjrx8zAvM_oAhUvhXIEHcBHDmYQFjAFegQIBxAB&url=https%3A%2F%2Farxiv.org%2Fpdf%2F1706.00333&usg=AOvVaw1OaEu0ozlfTlaN1ZTfb-IW     paper, increasing the packet size above about 2000 bytes should substantially lower the error rate.  So far I’ve been able to get the packet size up to 2400 bytes using jumbo frames, but I have not finished the network driver in order to test it.

Next week I mainly plan to focus on hardware, and possibly finish the network driver.  As a stop-gap, I’ve been able to capture data using wireshark and write a short program to translate those files to the logfile format we’ve been using.