Tasks :

• Full integration complete
• Ran compass tests (measure at known angles, check whether prediction within error bounds)
• Ran latency tests (difference between hear sound and symbol appears)
• Prepared for final presentation

Deliverables:

• Video
• Blog Post
• Final Report

This week saw some good progress on the software side. Most of this was done with pair-programming with Ram.

• Input audio form correction. Previously each mic input was biased from 0 by a certain amount. We adjusted each audio waveform such that it is centered around 0. This means that as far as the acousticSL library is concerned, the audio activation level would be consistent for all waveforms (i.e no 1 waveform is arbitrarily larger or smaller than the other).
• Integrated the 4 microphones into acousticSL (through multiple library and callback instantiations). We also derived an ad-hoc implementation for reconciling the output angles of TDOA on two pairs of microphones into a single output angle (through a mix of adjusting to a common reference angle and then taking the measurements that are consistent from both microphones). The ad-hoc implementation is taken with reference to a parallel line going through one of the mics so this further refinement.
• Augmented the square sums smoothing for both the raw input angles and also the converged angle from multiple measurements.
• Rough latency test is promising; precision test is still worrisome

To-Dos for this week:

• Robustness to noise and adjustments for precision (at least get to 30 degrees for the OLED screen)
• Increasing the sampling frequency; balancing smoothing and latency (i.e how much to smooth, how long to smooth)
• Add a third pair of mics (possibly adjust the physical arrangement) to improve angle resolution
• Move data processing logic gradually into callbacks — this might allow us to be more lock-step when interacting with acousticSL

Some geometry of interest:

Tasks accomplished this week:

• Ironed out some data acquisition bugs about resolution and sampling speed (our current design that marks data as ready in callbacks but only does data copying in the run loop will result in poor predictions). As such we will likely do data read/copying in the callback and de-prioritize the OLED update: similarly, we will probably use this to lockstep calling of multiple acousticSL instances.
• Tried solving Ram’s debugger issue 🙁
• Investigated into some counters. This paper discusses probabilistic counter updates which argues that probabilistic updates can match other counters with less bit-width (https://zilles.cs.illinois.edu/papers/probabilistic.hpca2006.pdf). The paper also conveniently lists other counters we can use. We will still need some more discussion about how we exactly want to do this based on the # states our OLED can display and counter resilience so our device’s reaction time remains within the target.

Unfortunately couldn’t get as much done as liked during this week. Got a flu shot on Wednesday and then proceeded to get a high fever shortly after. Still recovering so Ram and I will proceed remotely once we do an equipment hand-off.

Tasks for next week:

• Fully implement 4 mics and correct the audio angle
• Test to see whether we meet the target metrics

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:

• 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:
– 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)

1. Performed current/power calculations for determining the battery
2. Finalized BOM with team together
3. Worked and codified design and slides with rest of team
4. Investigated osxAcousticSL library interfaces