Ethan:

Last week, I uncovered a serious bug in the networking stack. The ESP32 has limited stack space on the kernel, and the WiFi stack was being overrun by code from the ICMP and UDP handlers. This was causing intermittent memory corruption and stack overflows.  

The network stack was initially very greedy, so this was taken as an opportunity to revisit some of the functions, and do refactoring. 

The WiFi stack had some of its monolithic functions split apart, and now supports reviving and sending sending packets on different threads. This is helpful, because one of the issues was that the packets kept dropping when the buffers were full. The WiFi stack itself couldn’t be put to sleep while the buffers cleared because then incoming packets would be dropped. Now we can safely retry packets without tying up incoming packets. 

Granted, a natural consequence of all this is that the WiFi stack now introduces more latency, and requires a larger static buffer to hold queued packets. However the latency also only becomes apparent in poor network conditions, when packets need to be retried multiple times. This is acceptable to the alternative, which is more dropped packets and disrupted audio playback. 

Michaela:

This week I have been focusing on getting my system enable to work with the ESP32, as well as working on the system that will work on top of the scheduler (which we have titled “the dispatch” for ease of referencing).

I was initially having issues with getting my device to work with the ESP32, but after setting up a VM and debugging that, I was able to get it to work. With the dispatch, I was able to take the higher level design I worked on with Ethan and begin implementing it. At the moment, it is partially written with psuedo-code and calls to functions that have not been written yet. My goal for the demo is to clean this up and create tests that work without the ESP32 for proof of concept. My goal for the rest of the week is to complete this implementation and to work with Winston on any final changes to the enclosure that need to be made as the physical boards are here.

Winston:

This week I have focused on assembling our hardware, as the PCBs have arrived earlier than expected. I started on building and testing the power subsystem, as it does not involve any complicated firmware, and is the prerequisite to the proper functioning of all other subsystems.

Team:

Surprisingly our hardware actually came in earlier than expected. We are still beginning the integration process next week. Our initial plan was to showcase the begins of this integration during the demo next week, but with it pushed to Monday rather than Wednesday, we are simply going to show the pieces functioning independently to the best of our abilities.

In the coming week we we will work together to integrate the networking and UI code and then the hardware, and then further deal with any bugs therein.

Ethan:

What did I do this week.

This week I continued work on the networking and routing stack. The network stack was started last week, and I stayed in Pitts to work over vacation.  I implemented portions of ICMP6, network interface management and back-ported the virtual drivers onto the esp32. They were previously only targeted for osx. This allowed for rapid development and debugging. The code now cane compiled for either the esps32 driver, or the osx virtual driver interface. This dual architecture support is what will underpin our later hybrid virtual/physical mesh adversarial testing models.

The goal for this week is to continue to iterate on networking functions, and build a  UDP based music stream for our demo on April 1st.

Michaela:

This week I mainly worked on the enclosure. Initially during the week, I worked to finish my Ethics assignment and respond after our section discussion. I then created the model we will 3D print in CAD. An image is included below. The dimensions for the oval prism were included in my previous post, but I also created a band of about 32cm, which is the average length of all of my teammates top left ear to right ear going across the top of the head. This way, we can appropriately test a solid fit over our heads. We plan to have this 3D printed for our demo. Next week I plan to work having a Python implementation of the noise cancellation system in place so that we can having an example prepared to also include for the demo.

***

***

Winston:

This week I finished the schematics, which passed all our SPICE simulation tests and produced a BOM within budget.

Schematics (PDF file)

Excerpts of Simulation Results:

I will finish the layout by Monday morning and will work on firmware (e.g. drivers for our chipset) henceforth.

We, as a team, has discussed the adjustments necessary to catch up with the massive delays in hardware design.

Team:

In terms of team work, we have a large discussion about our current schedule. We went over with each other what we have left to do, what we all were currently doing, and our goals for the coming weeks in relation to our own and each others work. 

Our previous issue with the PCB has been slightly mitigated as the design is complete and we are prepared to support each other in the coming weeks to all get the hardware working.

Ethan:

My main personal task this week was starting to work on the implementation of our network protocols. This is the IPV6/IMCP stack. It’s alot of work since it’s being built from the ground up. I spent a significant amount of time in the lab, working on laying down the initial C structs and functions. I think that what I learned is that I need even more planning given the scaler of the software I am trying to create. I have to make a protocol, as well as both virtual drivers (for testing), real drivers (for hardware), and write test suites. To that end I started on a new, higher level implementation document that focuses on documenting the structure of the code I wrote. This helps when managing the complexity, as well as being a source of documentation to look back on.

I hope that by next week I will have enough of the protocol working to test between an ESPS32 and a computer. I will also have a more polished  implementation document I can use for reference.

Michaela:

This week I worked with my team to complete the rest of our design document. I wrote the sections regarding the signal processing elements, as well as the introduction portions and the ending project management portions (excluding the budget and schedule in the appendix).

I also worked on establishing key aspects of the enclosure design to work off of. The first is that cup of the cans will have a major axis of length 9cm and a minor axis of 7.5cm. This way we can fit the cups we bought. Also, we will have them be cylindrical in shape, rather than tapper, so we as to prevent the production of unnecessary and expensive scaffolding in the 3D printing process. At the moment, I am trying to determine the best way to fit all the components into the enclosure. The goal is to keep it within a 2.5.cm width, but that may change while considering the necessary padding and waveguide horn that must also go in along with our other components.

Next week, I plan on completing this design as well as our Ethics assignment.

Winston:

Team:

In terms of team work, we all completed our parts of the design document and reworked it into our final product.

In terms of scheduling, Michaela is a bit behind on her first filter iteration, but that is being handled within the next week and  is not required for any work in the next couple weeks.

Ethan is also behind schedule – he is planning to handle it within the next week as well. He ran into some difficulties writing the implantation for his networking code. We spent several hours going through each item on our task list, and setting new due dates, as well as writing small descriptions for the task. This served a two-fold purpose. This allowed us to update our schedule, as well as “resync” and make sure we were all on the same page for the status of our project.

Right now, our biggest risk is the hardware. If the PCB’s are submitted late/do not work that will impact our critical path and shift the entire schedule down. We are attempting to mitigate this by having a professor work with us to review out design. We have not made any major changes to our design, but have further refined our physical enclosure and mesh software designs.

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.