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.