Our final report is attached here: Team_B5

 

 

This week, we made some good progress on the software side (Will and I pair-coded for most of this).

• We did some code clean-up that made transitioning to 4 mics easier
• Geometry: we did the math to figure out how to reconcile the output angles of TDOA on two pairs of mics, and implemented this
• We debugged the existing solution for smoothing, and improved it some more, to balance the trade-off between latency and smoothness
• Did a rough overall latency test which was promising
• We still do not have 15 degree precision based on some rough tests, so we will need to work on that
• Unrelated: Found a potential fix to my laptop issue

To-Dos This Week:

• Make it more robust to noise – if there are very loud and close-by keyboard noises, it currently does not work
• Adding a third pair of mics – either an actual third pair in between the current ones, or a “virtual” third pair that uses data from two mics that are currently part of different pairs
• Increasing the sample frequency – we don’t really need to yet, but we anticipate that we might need to do this soon (so that we have more breathing room in terms of latency, and less lag when transitioning)
• Move a lot of the code currently in the main while loop into callbacks – the advantage of this is that these callbacks can’t be interrupted so the volatile variables that we change will definitely not be modified in the middle (currently, this isn’t a problem but it could be so it’s probably good to do this move)
• Smoothing Improvements
  • Account for 0 essentially being the same as 360 – so that the smoothing algorithm takes into account the fact that changes from e.g. 3 to 359 are actually fine, and these are still smooth
  • Implement a feature where if we haven’t seen 10 angles in a row, we just cut off all our prior sample knowledge – because those priors are likely unreliable

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…

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

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:

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:

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).

1. Did calculations to make sure that sampling frequency was sufficient, and that for reasonable distances the angular resolution will also be good
2. Did order-of-magnitude calculations to check that our response time will be < 500 ms (can’t say with certainty yet, but seems to be in the ballpark, under 500 ms)
3. Looked at possible time-domain implementations of gcc-phat
4. Worked on design review points, and slides with the team
5. Finalized our BOM with the team