Team Status Report for 2/10

Summary of Accomplishments

This week, we presented our proposal and received feedback from faculty. Here are our thoughts:

  • Robustness of the audio system is a good idea: we need to factor in making our data collection more robust to “noisy”/bad data.
  • In average mode, the average incorporates data gathered since the beginning of the session.
  • The intended device use time = 8 hours before recharging, since that’s about how long Professor Dueck says people work for.
  • The timespan of instantaneous = 1 second (response time goal).
  • Bracelet networking is an interesting idea, but we envision our device as an individual solution.
  • Directionality will be incorporated. With multiple microphones, data about varying sound levels in different directions can be gathered.

We also met with Professor Dueck, Assistant Professor for Collaborative Piano and Vocal Coaching, whom we are collaborating with for our project. She introduced some use cases, such as how some practice rooms they were given weren’t designed with acoustics in mind so they weren’t very comfortable to use, or how orchestral musicians are concerned for their hearing because they are surrounded by loud instruments but still have to hear details in the music. We are looking forward to meeting with her and her students on Monday so we can interview more potential users to better understand what features would be most beneficial for them and what else we can improve for our design.

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?

Currently, the most significant risk we foresee is that parts will be damaged in the fabrication or testing processes. To mitigate this risk, we intend to order multiple copies of electronic components (5+ of each?).

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?

Firebase will no longer be used; its purpose can be fulfilled by Django. The LED strip choice was changed to Neopixels, because it runs on a lower current, so our battery can last longer. The design now has a specific choice for microcontroller: the Beetle ESP32 C6 Mini Development Board, for its BLE capability, small size, and safety (wearable safety is not explicitly stated, but two of the applications on the store website are wearable devices). Our battery choice is two 3.7V 2000mAh lithium-ion batteries to facilitate a longer use time while still meeting our size requirement. With these components decided, our plan for layout is to have the batteries on the top and bottom of the wrist, with the microcontroller between them on one side, leaving the fastening mechanism on the last “side”. The microphones can be placed about equidistantly around the wrist, so it’s likely they’ll land on top of the batteries/microcontroller area.

Provide an updated schedule if changes have occurred.

The Gantt chart has been updated to reflect that materials were not finalized until 2/10 instead of 2/7. Also, ordering parts will begin on 2/12 instead of 2/8.

Leave a Reply

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