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:

This week I continued work on the wireless system, however our focus pivoted to the high level systems required to make the headphones work. I discussed this with my teammates at length to make sure we were all on the same page and could code together. 

Unfortunately, my responsibilities during the carnival season, as well as my 349 lab partner dropping has had a decidedly adverse effect on the amount of work I got done last week. I am behind on wireless optimizations, and my current tests still put me at a maximum of 600,000 bytes per second. While that number meets (and exceeds) the bandwidth requirements of our project, it is not fast enough for the latency requirements. We have have an effective bandwidth an order of magnitude higher than the bandwidth required for a single stream because as we make more hops, our maximum ELS (effective link speed) goes down. 

Given the pending date for demos, I plan this week to pivot my focus to making sure the Audio playback is smooth and (hopefully) integrating the software with the physical hardware that should arrive sometime this week. 

Michaela:

Though I was fairly ambition in my plans for this week in my last status report, there were a few unexpected occurrences that deterred me from accomplishing all that I wanted to do.  We have decided as a group that rather than printing the headphones now, we will wait until all the components are assembled and testing is done, as this might effect our budget and thus lower the allocated printing budget. After discussing the higher level software more with Ethan, we have come up with a system that will run on top of the scheduler of the ESP32 in order to properly pass along resources to our necessary operations and run them as efficiently as possible.  For this reason, I reworked the FSM and UI code a bit and started working on creating the necessary aspects of this system, such as the tags that will be assigned to each scheduled task. Other than that, due to issues arising involving Buggy filming and overestimating my energy level after these days of work, I was unable to complete much else. With this winding down and the final in lab demo approaching, I am hoping to have this code and test cases prepared by the end of next week.

Winston:

This week, per Prof. Tamal’s request, I updated the layouts of PCBs with stricter design rules, bumping minimum clearances from 3.5mil to 5mil, minimum trace width from 3.5mil to 6mil, and minimum distance between drill and copper from 0.2mm to 0.25mm. More than 2000 traces have to be moved manually; these more stringent design rules are largest satisfied, with few exceptions, and thus minimize the critical area in these boards.

The endeavour to implement firmware continues. The push in schedule is compensated by pulling more time out of Carnival to work on this project.

Team:

As a team, we are currently trying to prepare for the inevitable debugging that will need to take place when we integrate our components. Overall, we are trying to build test cases and scenarios, such that we can mitigate the issues that will arise once this occurs.

Moreover, as a team, we set ourselves a soft deadline for the completion of the software system to be the time that hardware is shipped and assembled, which is expected to be Apr 21.

Ethan:

This week, I made a major push to finish up the network routing code that had been demoed at the interim demo on Monday. I initially implemented a layer 2 packet switching system, but unfortunately as my implementation was nearing completion I discovered that layer 2 switching was not possible with the current revision of the ESP32 wifi chip we were using. I spent Friday rewriting the network stack to route packets on the layer 3 level instead of the layer 2 level. The other big thing I worked on was network throughout optimization. Because of the tight timing requirement involving networking packets the networking code had to be profiled, and benchmarked, The current networking code takes approx. 500 micro seconds to process a packet with max MTU (1024 bytes), which is not fast enough.

The current networking stack is slightly behind schedule, but since we are readjusting scope to a static mesh configuration right now all that needs to be done is it needs it’s performance to be tuned. This week, I hope to finish those optimizations and rewrite the audio driver we used during there demo. However between 349, secure coding and my spring carnival responsibilities I am not convinced I will be able to direct the same energy into capstone I did last week. There are a lot of important projects currently vying for my attention. 

Michaela:

Along with working on my reading assignment this week. I added the last final touches to the headphone can 3D model by adding Winston’s boards. We are looking to have a print done by the end of next week. Additionally, I have begun writing the comprehensive list of all the tasks/modules we will be utilizing for our high level software. This includes the inputs and outputs, runtimes, related tasks, and general functionality. With that, I also created the files for our basic fsm and related UI which will be controlled by many of these modules. Next week, I hope to finish this list and begin writing the rest of the modules. Given that next week is Buggy and I am one of the individuals in charge of the filming crew, I expect that the week will be fairly busy, but I am optimistic that I can still accomplish all of my goals.

Winston:

The PCB, the corresponding SMD stencil, and electronic components have been ordered. There are 90 different parts that need to be ordered and will be 344 discreet components to be soldered onto the 4 pieces of PCBs.

Here are the finalized CAD and CAM files:

	Left Main	Left Side	Right Main	Right Side	Panelized
Schematics	Download	Download	Download	Download	–
Layout	Download	Download	Download	Download (Original) Download (Rasterized)*	Download
3D Model	Download	Download	Download	Download	–
Gerber Files	Download	Download	Download	Download (Original) Download (Rasterized)*	Download

* The hatch pour in rasterized version is replaced by ~800 segments of wires of assorted lengths. As such, the rasterized version allows for edits like rotation, but is much slower to load.

Other than panelizing the PCBs and preparing the BOM for production, I also shifted gears and started the work on software. In particular, I started to work on the firmware for MGC3130, our gesture sensor.

I will continue to focus on the firmware in the coming week or two, until the ordered parts arrive.

Team:

As a team we further discussed what we would need to eliminate from our project in order to narrow the scope. These are the items we identified in order to do that:

1. Statically configure the mesh
2. Eliminate feedback topology in active noise cancellation (set initial filters for all of runtime)
3. Use breakout boards instead of PCB (our budget allows for both)

Additionally, we worked together to reach a consensus on how our high level software will look. Specifically, we discussed the role of the scheduler and the various tasks that will be run on it. We also discussed generally what modules we would be creating to be run as these tasks and how we plan on relating it to the other aspects of the project, such as the hardware and the networking.

Ethan:

This week, my main focus was preparing for the demo. In order to do that, I had to do a lot of work to finish the v0.1 of the networking stack. For the networking stack, this week I implemented routing link tables as well as converting the existing IPv6 code to use no dynamically allocated buffers. This also involved rewriting several previously buffer heavy implementations of networking functions with zero copy replacements. In some areas of the code, dynamic message sizes forced a worst case stack allocation to avoid a buffer overflow. As as result, while incoming packets are only bounded by the static Wi-Fi buffer, outgoing packets are artificially bound to a maximum MTU of 1200. This will probably change going forward, but more improvements are needed to the network stack first.

The network stack is also unstable, and crashes if it gets too many packets.

In addition, my other main focus was bringing the software to a point where it was able to be demoed. This required first working on the networking stack, and bringing to a point where it can talk with other IPv6 complaint devices in a minimal direct link. Full packet routing is still being implemented, and is not yet ready. For the demo, I worked on researching how linear PCM packets are processed, as well as working on a demo that used the IPv6 stack to forward audio from a target computer to the headset. Our next goal is to implement routing, so that the headsets can relay audio to each other.

We also need to continue to improve our audio playback protocols and buffer systems. Currently the audio playback is choppy, because even small variations in packet delivery time can cause the DAC hardware to miss it’s deadline. This is very noticeable for even small interruptions. In order to address this, we are working to develop a packet buffering and synchronization scheme to make the headphones more tolerant to jitter in packet arrival times.

I ended this week by completing the first audio demo, and testing it tonight. As mentioned earlier, it does not sound very good, and more refinement is needed for demo day.

Michaela:

This week I actually went back to the enclosure design to edit the formation of the cans to better fit the new form of the PCBs. I also began implementing the RLS algorithm in Python with receiving PCM packets and removing generated noise. I struggled more than expected with the implementation, so I went back to the original algorithm and went over it in writing. This allowed me to be more clear on what I need to accomplish. My goal is to still complete this before the demo period on Monday, as well as add the models from Winston once they are all complete.

***

***

***

***

***

Winston:

This week, I focused on working on the layout of the boards, making sure that they:

1. respect the dimensions set forth by Michaela along with reasonable placement of M4 screw holes,
2. all PCB designs combined fit within a 100mm x 100mm square, for lower manuefacturing costs, and
3. FPC, USB-C, and JST-PH connectors are arranged in a physically realizable manner, accounting for headroom for jumpers.

In terms of design decisions, I fused the previously top and bottom PCBs into one main PCB, which eliminated the need of FPC connectors and reduced the number of screw holes required. However, the trade-off in this decision is that the PCBs would take up more real estate. Fortunately, the four boards (namely main and side, left and right) still satisfy the second aforementioned constraint.

I also generated 3D models of the PCBs, utilizing the 3D models built previously.

I started designing the augmentation that needs to be made to the FreeRTOS event scheduler, which would constitute to our software architecture. I wanted to focus on implementing some of the firmware, but the team has agreed on the importance of our architecture and thus the switch in work priority.

I will focus on implementing the aforementioned architecture next week.

Team:

In terms of team work, we had a meeting with Professor Tamal to discuss our current schedule. Since we are behind progress, especially in terms of our PCB, we have come up with a Plan B in case it does not work or does not arrive in a reasonable time.

Below we have listed the outline for this plan, the ways it is different from our previous implementation, and the block diagram for this proposed plan.

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.