General updates
Due to significant differences in different sound apps reading the same sound, we decided to narrow down the variables involved by all downloading the same app and placing votes as close together as possible. We still get different dBs for the same app, but we also have different phones/mics, which we can’t control. The standard deviation between us is about 3 to 4 dB, which is outside of our desired range of being within 2dB of accuracy. The problem is, we don’t even know who is the most accurate, only that we are precise. Luckily, Prof Sullivan offered to give us a more trustworthy decibel meter starting the week after next, which can hopefully clear up this debate permanently. We will be taking it to practice sessions with the music students that we have been coordinating times with.
We also discussed microphone signal processing in our weekly meeting with Prof Fedder. Since microphone noise is negligible compared to the loudness we’re measuring, and we’re only interested in measuring loudness, filtering out noise probably isn’t necessary. A basic version of mic signal processing would measure the amplitude of the incoming signal a certain number of times per second and linearly scale that to dB levels. A more sophisticated version would use an FFT (https://projecthub.arduino.cc/abhilashpatel121/easyfft-fast-fourier-transform-fft-for-arduino-03724d) to see the “spikes” within the frequency range we are interested in, and take the maximum of the spike amplitudes. The problem with either version is that in order to account for frequency overtones and Nyquist’s theorem, we need to sample thousands of times per second. This might be computationally expensive.
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
The PCB doesn’t get here on time (expected arrival Tuesday). Given how much this delay has blocked our progress this first iteration, when we order the final (flex) PCB, we plan to pay extra for fast shipping instead of regular shipping, since we have enough left in our budget.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
No changes were made to the existing design. We’re still planning to order a flex PCB with the final design once we have tested the rigid prototype PCB and noted what changes need to be made.
Provide an updated schedule if changes have occurred.
The schedule has been updated. PCB creation/delivery took longer than expected, and a lot of tasks depend on us having the PCB, since a lot of the components are tiny SMD things that we can’t try to do by hand.
This is also the place to put some photos of your progress or to brag about a component you got working.
Here is a picture of the stencil for our PCB.
Gantt Chart changes:
Software: Due to difficulties in getting the Bluetooth connection to work on the mobile app, we have allocated an extra half a week to figuring it out. Additionally, the decibel reading display and visualization algorithms have been moved forward so that they can be done by the interim demo (4/1). Since full integration of the bracelet and the web app won’t occur until after the interim demo, these pages will be displaying information using dummy data.
Hardware: Electronic prototyping/PCB assembly and microphone signal processing have been moved forward by a half-week as well, because we can’t do much without the PCB being physically here.