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.