• Worked with Will on getting the 2 mic set-up to work with the breadboard mics, tuning the parameters so that the estimated angle did not unecessarily react to noise while reacting correctly to human voice, and testing that it worked correctly for a 180 degree angle range.
• Added some code to address a noticed issue of the angle estimate being very jerky when transitioning from one angle to another (e.g. when the person is moving). This code does some averaging over recent samples to smooth the angle estimate, and only outputs a confident angle when the recent estimates don’t jump around too much (tested, does not completely work, need to tune some parameters and make it work).
• Added some code to integrate the OLED functionality with the direction-finding functionality (untested with the OLED).

To-Dos:

• The smoothing code does not yet work – some more debugging needs to be done on this.
• To test whether the code to integrate with OLED works, need to meet up with Leon and connect the OLED with my board to check.
• Need to add in two more mics, and code in order to reliably distinguish which mics are faced towards the direction of sound. May have to add more, depending on how well we can do this (but it seems that 4 is good as of now).
• Ideally, we’d like to more rigorously test that we meet the 15 degree resolution in the static case (of someone being stationary and talking). This seems to be the case, but we haven’t really rigorously measured out the angles exactly.

Tasks Accomplished:

• Tested and verified an initial prototype working implementation of sound localization via acousticSL (can identify auditory inputs from places within a 360 degree angle using the CubeMonitor).
• Tested and integrated against the prototype CAD model’s two mics utilizing the same data line (this verifies that we can have 2 microphones that capture different audio share the same data-line input to the DFSDM and be able to run parallel outputs)

Deliverables for next week:

• Some noticeable issues that we encountered was: (1) noisy angle detection — which may require adjusting the noise-activation level of the algorithm or software smoothing and (2) amplitude biasing of the microphones — where the audio signal amplitude is offset from 0 by some fixed amount depending on the particular microphone
• The target for next week is to address the two issues above along with integrating the other two microphones together.

Tasks Accomplished

This week saw some pretty significant progress compared to last week. Primarily, we have been able to hook up 1 microphone to the DFSDM inputs of the MCU and sample it successfully. We have also been able to verify through CubeMonitor that we seem to be picking up real sounds. We have done further investigation of the downstream software pipeline so the microphone + MCU integration can proceed smoothly. On the hardware end, we finalized the CAD design for the display module along with ironing out some specification issues with the OLED screen.

Potential Risks

Time is our biggest issue with regards to the interim demo. Although most of the pieces are coming together (i.e hardware and software are both progressing at a decent pace and with a clear roadmap ahead), there is still risk in the microphone system from hardware limitations (i.e DMA read/write speeds, inefficient FIR/osxAcousticSL implementations) and risk in terms of fabrication. Barring significant surprises, we have controls for errors encountered in hardware/software pipelines (i.e scaling back/more microphones, adjusting sampling) so we are still confident in hitting the interim demo.

Tasks Accomplished:

• Worked closely with Ram to setup single microphone sampling using the DFSDM. Currently, we’ve verified that the 8 kHz output sampling rate can be continuously written to and read from memory via the DMA
• DFSDM unfortunately does not have built-in capability to do band-pass filtering. Based on this link (pg 11/56), a digital microphone typically has a 4th order sigma-delta modulator with strong off-band quantization noise. We anticipate we will require possibly a 5th order Sinc filter but would require looking at gathered data/fourier-transforms to get better insight.
• CMSIS conveniently provides a sample (here is just some link to some sample code) for implementing FIR filters. FIR filters depending on the coefficients and windowing can be used to generate a software filter. The annoying part is determining the FIR coefficients. ScopeFIR (commercial software with a trial) allows for specifying frequency bounds and various window settings and # coefficients for filter design. The image below is an example. Fine-tuning the filter (if needed) will be next week’s task.
  

Deliverables this week:

• Close work with Ram to get a 2 mic sampling setup working
• Integrate 2 mic sampling with osxAcousticSL (anticipate some fiddling with DMA settings and such)
• Based on FFT analysis, figure out the exact filter parameters and targets we need (in reverse, we may not need a filter!)

Tasks Accomplished:

Successfully set up the sampling from a single microphone using the DFSDM,  and debugged it! It works correctly for now (right now, we’ve set it at low frequency – 8 kHz – but this parameter can be adjusted as needed so this should not be an issue).

Used the CubeMonitor to get a visual representation of the audio signal – tested it to make sure that it’s picking up real sounds (originally, we were just looking at bytes in memory locations).

Deliverables This Week:

Investigate what sorts of noise are most prevalent in the audio (there’s a DSP library allowing us to do FFTs – use this to get a frequency profile so we have a clearer idea of what other filtering on top of the DFSDM we might need).

Get two mics working – specifically, make sure that we can correctly set up two mics to sample in one data line, managing the interleaving etc. properly as needed.

Once we’ve two mics working, run the data through the AcousticSL library and test that we can pick up on the direction! (No display module yet, but we can check that the right value is stored at relevant memory locations).

Tasks Accomplished:

• Completed final design document
• Installed STM Cube IDE and development environment
• Experimented with blinking a LED attached to a GPIO port
• Continued researching DFSDM interfacing of the PDM microphones using a source linked here

To-Do This Week:

• Receive input from 2-4 mics
• Configure osxAcousticSL in 2 mic setup and explore the implications of multiple library instantiations
• Experiment with DFSDM sinc filtering to see effectiveness against noise

Tasks Accomplished:

Design Doc was completed and submitted

Received parts, installed Cube IDE, toyed around with a basic program.

Figuring out how to corrrectly connect the mic to board and retrieve the audio samples using DFSDM, by reading these two resources: here, and here.

To-Do This Week:

• Successfully get input from two mics and pass it to the Acoustic SL library
• Preliminarily see how well GCC-Phat performs
• Tinker with DFSDM input filtering to improve performance as needed
• Address open issue from last week of head tilt (mathematically it didn’t seem to be a problem, and since we are getting the parts now, we can just check using the real set-up once we figure out the microphone sampling)

Tasks Accomplished:
– Worked/working on design presentation/docs
– Investigated DFSDM filter setup and integration

To-Do:
– Run a few DFSDM filter simulations and implement
– Implement TDOA (with Ram)

Tasks Accomplished:

Finished the design presentation

Working on the design documentation

Received most parts except MCU

Some preliminary testing of the optical set-up

 

To-Do:
Start building it and coding it up once everything’s here!

Tasks Accomplished:

Presented the team’s design

Worked on the design presentation/docs

 

To-Do:

Right now we’re waiting for the main part, the MCU, to arrive so we can start implementing our design. This is when the major work begins. Another to-do is to double-check that head tilt does not affect (preliminary math calculations suggest that this is the case, but maybe a simulation would be good, depending on the time vs reward tradeoff).