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.