Status Report #10

Ethan:

This week was focused on system performance and the high level software. I was involved in extensive talks with my teammates about the implementation of high level software. I also ported the SBC encoder and decoder from Bluedroid in order to work with our software. It resulted in 4.4 times less data being used for the same amount of music. I also worked on the presentation for our project. This next week, we plan to finish the implementation of the high level software, and get it running on the final hardware. 

Michaela:

This week I completed what I set out to do from my previous status report. The dispatch has been completed and ran as expected during the demo. Additionally, the final design for the enclosure cups has been established. It is scheduled to be printed, but not in time to include images for the Final Presentation. For this last week before the Final Public Demo, I will be working along with Ethan to finish the high-level software that has the two ESP32s in each cup working together, as well as then connecting to the hardware Winston is finishing up.

Winston:

Lorem Ipsum

Team:

At this point, we are simply working to complete our system for the demo. We are aware that there will be much debugging to be done when all the components come together, but we are prepared to work together to get this completed (along with the Final Presentation and Demo Poster) in the next week.

Status Report #9

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.

A Photo of PCB Assembly Equipment, including a digital microscope, a vice, and a hot air gun for assembly
A digital microscope, a vice, and a hot air gun for assembly

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.

Status Report #8

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.

Status Report #7

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.