Team Status Report for 4/6

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 most significant risk is that we do not finish in time. As of the interim demo, web app progress is proceeding well, but hardware is somewhat behind where we expected to be; for example, microphone signal processing is taking much longer than anticipated. This risk is being managed by trying to do tasks that require significant waiting (like ordering parts or PCBs) as soon as possible, and by having multiple versions of the PCB to test with.

The second most significant risk is that the microphone output does not correctly connect to the PCB ADC input, making it impossible to extract meaningful data from the microphone values. This is being managed by implementing a peak detector circuit between the microphone and ADC on one of the final board designs. If this issue is due to loose connections, then the original design on flexPCB will work as expected once everything is soldered together; if this issue is due to some fundamental problem with the mic-PCB relationship, then the peak detector circuit will resolve it. If this is an assembly issue due to how tiny the mic is and how difficult it is to solder precisely, making many boards will help solve it by increasing the expected value that at least one board will end up with working components.

This is Prof. Fedder’s sketch of how the peak detector circuit should be included in the overall design.

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?

Changes were made to the block diagram: for one version of the final design, a peak detector circuit (composed of 2 resistors, 2 capacitors, 2 op-amps, and 2 diodes) now exists between each mic output and microcontroller ADC input.

Provide an updated schedule if changes have occurred.

All code, assembly, and testing must now take place before April 21st. The flexPCBs will be ordered this week.

Now that you have some portions of your project built, and entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements? Verification is usually related to your own subsystem and is likely to be discussed in your individual reports. Validation is usually related to your overall project and is likely to be discussed in your team reports.

We have not yet run any of the tests under the explicit rules stated in the design review, because they require either a complete bracelet or a complete mic-LED system. Since the results of each test are directly related to the requirements, considering which requirement is fulfilled by passing each test (with reference to the chart in the design review) should suffice.

Leave a Reply

Your email address will not be published. Required fields are marked *