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

My debugger program (Cube Monitor) stopped working this week so a looot of time was sunk into debugging it with no success yet. So the plan is, now that I’ve pushed all the relevant code to the remote repo, we’ll work from Will’s computer and pair-code until/unless I figure this out.

Also, we figured out how to structure our code to get 4 mics to work, and we need to implement that.

I also debugged some code involving removing the arbitrary mic offsets we observe for different mics – not 100% sure if it works yet though (it was in the middle of debugging this when I realized my Cube Monitor was broken).

One of my mics wasn’t working properly in stereo – spent some time and eventually realized that it was because the stereo connection wasn’t cut properly so cut that and it was better.

To-Do:

• Fix this annoying software bug whose source is still extremely mysterious to me
• Get 4 mics working properly, and test it out on Will’s computer
• Test, see if we meet our metrics next week – if we do, then we can begin to think about stretch goals like classification, if not we’ll need to work on getting latencies down or accuracies up…

Tasks Accomplished

This week we saw the most progress in our hardware, namely we now have physical fabricated versions of our designs for us to devleop with and iterate upon. We also saw some integration work in the display side, with a working driver for the display unit. <More stuff here…>

Potential Risks

Time is again our biggest risk, especially since these weeks are extremely tough with large workloads from other classes. Physical design of the harness and assembly takes time, and so does the printing of the design, making it one of our bigger risks for the upcoming weeks. Integration is looming ahead, and although most of the individual pieces are coming together well, integration requires all components to be ready in order to start. Also, since we have yet to do work on the battery unit, power consumption remains a potential issue down our road, as it requires us to optimize code to save on current draw.

• 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!)