Status Report #3
Ethan:
This week I focused on the design document. My team and I met after the presentation, and discussed the feedback we got as wall as what changes in direction we wanted to make to our design documents. We realized that our presentation wasn’t good because while it did an excellent job of explaining each individual part, it made little mention of the overarching goals of the project as a whole. A large part of this week was spent figuring out how to reorganize and present our project in a meaningful way. I wrote the draft for the mesh portion of the design document, which will be finalized tomorrow.
Michaela:
This week I worked on material for the design document. Mainly this has been taking the information from our presentation, along with the notes we received afterwards, to provide a complete overview of the design of our project from high to low-level. One of the major things we worked on together is discussing how to best layout the design holistically, rather than individual pieces. This included creating an explicit chart of relative areas/aspects of the headphones, features, metrics, and verification we wanted to hit for the project as a whole, rather than individual pieces. This way, we can explicitly state why we are doing and including certain things in our overall design. Another thing I worked to do is to create a list of buzzwords we used during the presentation, so that we could be sure to properly define them in when discussing them in the design document.
Finally, I worked on writing the actual design document.
Winston:
I focused on the design review presentation last Sunday; since then, I started to work with my teammates on the corresponding report, trying to re-organize the information at hand per the feedback with regard to our presentation. In particular, I was in charge of drafting the outline of the report according to the consensus from our discussion, since both Ethan and Michaela are quite preoccupied by the production of Lunar Gala.
In terms of hardware design, I started the layout of the schematics and the corresponding enclosure design. I found out that one side of the headphones is about 60mm thick (including cushion, audio driver, acoustic foam, electronics, and thickness of enclosure). The dimension is shown diagrammatically as follows:
Therefore, as a team, we decided to move the inductive charging receiver coil (which is reduced in size in the diagram above for clarity – it is actually 36mm in diameter). Specifically, it would be moved to the center of the headband. As a result, I cannot maintain the symmetry between the two sides of the headphones and thus have to put different components into each side.
We will further discuss how to reorganize our schedule to accommodate this unexpected change in hardware design.
Team:
We decided to organize the design report by features and high-level needs and wants, instead of by hardware, firmware, software, or algorithm areas. In particular, the breakdown is as follows:
| High-Level Requirement | Features | Competing Metrics |
| Good Sound Quality | Low-noise circuitry |
|
| Active noise cancellation |
|
|
| Passive noise isolation |
|
|
| Audio Sharing | Effectiveness and robustness |
|
| Ease to set up |
|
|
| Usability | Long battery life |
|
| Intuitive UI (gesture control) |
|
|
| Fast USB charging |
|
|
| Wireless charging |
|
|
| Basic Functionality | Bluetooth audio |
|
| Physical enclosure |
|
One prominent risk is the major revamp needed in hardware design due to the relocation of charger coil and thus the basic design principle of symmetry between the two sides of our headphones. We will resolve this by tomorrow.
Design Review Presentation
Status Report #2
Ethan:
This week, I have finished my mesh proposal document, and moved on to writing a more detailed spec. The spec is based off of the proposal, so it is coming along well. I also have a network document I am working on, that covers how the network adapter sublayer works. It’s mostly documentation meant for myself, so while it is complete I plan to spend some more time going back and making it more accessible to other people.
I also worked on the beginning of writing a raw packet application for OSX. The purpose of this application is to simulate network traffic to “fake” a mesh. The goal of this application is to provide a controlled environment for adversarial tests, as well as a debugging endpoint for physical devices.
The details of tracing the networking hardware are linked below. This document will probably come up a few more times in my reports, since I am adding to it as needed. As mentioned earlier, I’ve cleaned up the first half. The second half has not been cleaned up yet.
https://docs.google.com/document/d/1L7MFW3fkiBtsV0twK3tao40jIhDK2eEoh8rok_rGpqM/edit ?usp=sharing
Next week, our main focus is going to be the written design document.
Winston:
I am behind schedule, for two major reasons: first, I did not get any work done (including coursework outside of capstone) last Sunday to Tuesday due to personal reasons; second, I had to iterate on the hardware design for bettered software flexibility, higher power efficiency, and fail-safe support for firmware development and debugging.
This week, I created a managed library in Eagle that is custom to this project, so individual components can be made easily accessible from a single point of entry. I also added comments (green text) and grouped bus signals together (blue thick lines) in the schematics, as seen below.
The process of associating 3D models with components (i.e. the combination of symbol and footprint in Eagle) is quite arduous, since the UI of library.io, a web-based extension of Eagle, is poorly designed. Moreover, the web app handles complex geometry (e.g. a USB type-C receptacle) with a lot of glitch.
Iterations on the hardware include re-designing the soft-latch power switch. Originally, a design with two Schmitt trigger NAND gates is used to latch a momentary switch in hardware. However, it consumes around 130μA at quiescence. After redesigning that subsystem, the switch can not only be used as a digital input into the microprocessor, but also the power supply can also be turned off in software. The new design consumes around 15μA at quiescence.
Furthermore, USB PD 2.0 negotiation capability is added, just in case that wireless charging is not as performant as expected, and we need to fall back on a more predictable solution in hardware. With design tweeks as such, there is more flexibility in our firmware or software design in the future.
Case in point, the DAC and class D amplifier combo chip that we are using can output either left or right channel audio, or an average of both, which can drive the speaker units in both sides of the headphone, freeing up the intra-headphone I2S line for mic audio communication.
I will catch up missed work in the coming week.
Michaela:
This week I worked on designing the FSM for the user interface. In that, I decided on the flow of different playback modes of the system as well as the user gestures that would controls these. I worked to make these gestures as consistent and intuitive as possible so that the user would not have too many gestures to remember, and the gestures would do similar things throughout the system.
I also then worked with my team to create our design presentation. Since I will be presenting this time, I also created my own set of talking points, so that our presentation will be concise while still hitting all the technical criteria.
TEAM STATUS:
The most significant risks for our project at the moment are outside responsibilities currently affecting all of our team members at the once. The largest of these being exams, papers, Lunar Gala production, and personal issues. We are managing these events by assisting each other during the times when the other is busier as to not get behind on our work. We are prepared to switch around tasks as a contingency plan in order to keep the timeline and the pace of our project.
Though there were no changes to any existing requirements or diagrams, we were able to agree upon the diagram for the user interface. This involved then agreeing upon the functionality of different modes of our system which we will then build upon during the implementation stages. We were also able to test our initially chosen polyurethane foam that would be used for acoustic isolation and passive noise reduction. In these basic tests we realized the foam would not be able meet our requirements for the hardware and the noise cancellation systems, so we are exploring other options.
Introduction and Project Summary
In this capstone project, we plan to create a wireless set of headphones, comparable to previously existing wireless headphones, but in addition have audio sharing capabilities. Audio prosumer technology has experienced rapid development in the last few years. Specifically the rise of wireless earbuds and headphones has dramatically increased the convenience of on-the-go listening. Individuals are no longer tethered to their devices and have more freedom to act as they so please while enjoying their aural experiences. In this new age of auditory freedom, one area that has still not been fully developed is the ability to share. If one wishes to, for example, share a song with another, they only have three options available to them: play their music out loud, potentially disturbing others; play their music through headphones and give it to the other person to enjoy alone; or obtain an audio splitter and connect two sets of headphones to a device. In an age of increasing wireless connectivity, none of these options are viable. With our project, we would not only be able to have a device that can satiate this growing desire for wireless audio technology, but also fill the void of communal audio enjoyment that is in the current market.