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.