Josef’s Status Report for 9/26

This week, I focused on researching the firmware and real-time software architecture for implementing ANC directly on the STM32. I studied digital feedforward ANC implementations using FxLMS and investigated how we can structure the processing around DMA-driven audio transfers and an RTOS. One of our main technical challenges is that commercial ANC is often implemented using dedicated hardware or DSP functionality, whereas our goal is to implement the adaptive cancellation algorithm ourselves in software. I therefore focused on the timing, buffering, computation, and scheduling requirements needed to keep the feedback loop operating in real time.

I also investigated the memory requirements of the ANC algorithm. We initially considered whether an external memory chip could allow us to maintain much longer audio histories, but decided against this direction because the ANC workload is fundamentally streaming and additional memory-access latency could work against the low-latency requirements of the cancellation loop. Instead, our current plan is to maintain small DMA buffers and only the recent sample histories required by the adaptive filters. This also makes the RTOS and DMA architecture especially important, since audio must continuously move through the processing pipeline without missing deadlines.

My firmware work is currently on schedule, although the software implementation will be one of the major technical risks of the project. Over the next week, I plan to begin implementing the RTOS-based firmware framework, DMA audio buffering, and the initial processing pipeline so that we can benchmark CPU utilization and latency before implementing the complete FxLMS algorithm.

May’s Status Report for 9/26

This week, I focused on researching and selecting components for our active snore-cancellation system. I compared different options for the microphones, audio codec, speakers, processor, power system, and other supporting components while considering their latency, power consumption, physical size, and compatibility with the rest of the system. I also spent time considering the physical and mechanical design of the wearable, including how the microphones, speakers, battery, heating elements, and electronics can be positioned while keeping the mask comfortable for sleeping and especially for side-sleeping.

I also contributed to refining the overall system architecture as we learned more about the constraints of implementing ANC. In particular, our research reinforced that the placement of the reference microphone, error microphone, and speaker is closely tied to the effectiveness and latency of the cancellation loop. Our current design therefore treats the physical geometry and electrical design as interconnected problems rather than designing the enclosure only after the electronics are complete.

My work is currently on schedule, although we need to finalize and order several components soon so that hardware availability does not delay integration. Over the next week, I plan to finalize the remaining component selections, help place our initial orders, and continue refining the physical arrangement of the wearable around the selected components.

May’s Status Report for 9/19

This week, I focused on the CPU selection and the general computing requirements for the system. I finalized the STM32H742 as our main processor and selected a development board that we can use for early experimentation. I also looked into how the processor would interface with the audio codec, particularly using SAI and DMA to continuously move audio data with minimal CPU overhead. Since the ANC processing is relatively focused, I also investigated using a bare-metal architecture rather than an RTOS. Finally, I considered power consumption and processing requirements to make sure the CPU provides enough performance for real-time audio processing without unnecessarily increasing battery usage.

Soma’s Status Report for 9/19

This week, I focused on identifying the current market for similar products and analyzing the characteristics of snoring noise. From the frequency analysis, I found that snoring contains frequency components extending much higher than we initially expected, reaching up to around 18 kHz. This may require us to reconsider some of our original system parameters and bandwidth requirements. I also researched possible form factors and battery options for the device. In particular, I looked into the safety concerns associated with LiPo batteries, since battery placement and protection will be especially important for a wearable device that will be used close to the user.

Josef’s Status Report for 9/19

This week, I focused on the PCB fabrication side of the project. I created an initial estimate of the PCB manufacturing cost and started drafting the PCB designs. One of the main challenges was working with flexible PCBs, since I had not designed with them before. I had to spend additional time researching flex PCB constraints, materials, and layout considerations compared to standard rigid PCBs. Despite the learning curve, I was able to make progress toward a preliminary design and a more realistic estimate of the fabrication requirements and cost.

Team Status Report for 9/19

This week, we made progress on both the hardware design and the characterization of our target noise. We began working on the bill of materials (BOM), finalizing our CPU and development board selections while narrowing down candidates for the audio codec and speakers. With the major hardware components becoming more defined, we are preparing to begin PCB design soon.

We also analyzed the frequency spectrum of snoring to better understand the requirements for our active noise cancellation system. Our initial assumption was that most relevant snoring noise would be concentrated at relatively low frequencies. However, our analysis showed that snoring can contain frequency components extending up to approximately 18 kHz. This is significantly higher than we initially expected and may require us to increase some of the bandwidth and sampling-rate parameters in our original system design. Moving forward, we will use these findings to refine both the hardware specifications and signal-processing requirements of the system.