This week, our team continued transitioning from system design into active implementation and subsystem testing. Last week, much of our work focused on preparing for the arrival of the development hardware, completing breakout-board designs, and establishing a programming and firmware strategy for the STM32. This week, we began using those preparations to bring up the first portions of the system and verify that the hardware and software architecture we developed earlier in the semester can operate as expected.

A major focus this week was initial bring-up of the STM32 development board. We first verified the basic programming and debugging workflow using ST-Link and SWD, confirming that firmware could be reliably flashed to the processor and debugged through the same interface that we eventually plan to expose on our custom PCB. We then began testing several of the low-level peripherals required for the audio-processing pipeline. Initial firmware tests focused on clock configuration, GPIO, timers, serial debugging, and the peripheral interfaces that will eventually communicate with the audio codec. Establishing this basic firmware environment gives us a stable platform on which the remainder of the audio system can be developed.
We also began implementing and validating the DMA infrastructure that will eventually support continuous audio streaming. Our system is designed around a 48 kHz audio sampling rate and block-based ANC processing, with the current design using 64-sample processing blocks.

Rather than having the processor explicitly move every incoming and outgoing audio sample, DMA will allow the codec and STM32 peripherals to continuously exchange samples while the processor performs signal-processing operations on previously received data. This week, we focused on establishing the buffer structure and DMA transfer model required for this pipeline, including the use of alternating buffers so that processing and audio transfer can occur concurrently.

The next major software milestone is establishing a reliable digital audio path between the STM32 and the audio codec. We began configuring the STM32 SAI/I2S interface and determining the clocking relationships required to maintain the selected sampling rate. Because the codec and processor must remain synchronized throughout continuous operation, correct configuration of the master clock, bit clock, frame synchronization, sample width, and channel ordering is particularly important. At this stage, the goal is not yet to run the full adaptive ANC algorithm, but instead to confirm that known audio samples can be transmitted and received without corruption, dropped samples, or timing errors.

Progress also continued on the audio-codec breakout hardware. The breakout board is intended to allow us to evaluate the codec independently before integrating it into the much more constrained final PCB. Once the board is fabricated and assembled, our bring-up procedure will begin with power-rail and continuity checks before applying power. We will then verify the codec clocking and configuration interface, followed by basic microphone input and speaker output testing. This staged approach follows our planned verification strategy of validating components individually before attempting system-level integration.

On the signal-processing side, we began preparing the existing Hybrid LxFMS simulation for eventual migration onto the STM32. Our MATLAB implementation has already allowed us to study the behavior of the adaptive algorithm, including the approximately 17.88 dB overall attenuation observed in simulation and its stronger performance at lower frequencies.

The next step is therefore not to redesign the algorithm, but to convert the major signal-processing operations into a form suitable for real-time embedded execution. In particular, we are beginning to identify the filtering, vector operations, coefficient updates, and buffer management that can make use of the STM32’s DSP and floating-point hardware.

We are also beginning to establish measurements that will allow us to compare the actual processor against the computational assumptions used during the design phase. Once continuous DMA-based audio streaming is operating, we plan to measure the execution time of each processing block, CPU utilization, interrupt frequency, buffer headroom, and end-to-end audio latency. These measurements will determine how much computational margin remains for the adaptive filter and whether the selected 64-sample block size provides an acceptable tradeoff between processing efficiency and latency. This will be particularly important as we move from simple audio passthrough toward real-time filtering and eventually the complete ANC feedback loop.
Hardware fabrication also continued in parallel with software development. With the breakout designs largely complete, the focus is now shifting toward producing the actual boards and preparing for assembly. This represents an important step because it will allow components such as the codec, microphones, amplifier, and supporting circuitry to be evaluated under conditions much closer to the final system. At the same time, work on the wearable enclosure and physical layout is continuing so that electrical design decisions remain compatible with the eventual sleep-mask form factor rather than being developed independently.

Overall, this week represented the beginning of hardware and firmware bring-up rather than simply preparation for it. The project is now progressing along the implementation structure established during the design phase: testing the processor on a development board, evaluating the codec through a custom breakout board, continuing development of the ANC algorithm, and developing the physical wearable in parallel.

Our primary objective for the next week is to establish the first complete audio path through the system. Ideally, this will consist of microphone or test-signal input through the codec, DMA-based transfer into the STM32, simple processing or passthrough on the processor, and audio output through the codec and speaker. Once this basic path operates reliably, we can begin introducing fixed filtering and then progressively migrate the Hybrid LxFMS algorithm onto the embedded platform.

This week, our team began shifting more substantially from the design and component-selection phase of the project toward implementation. Over the past several weeks, much of our work has focused on determining the overall system architecture, selecting the processor and audio components, understanding the requirements of the ANC algorithm, and determining how the electronics can be integrated into the wearable form factor. With most of these larger architectural decisions now established, we have started ordering development hardware, completing breakout boards, and preparing the firmware that will allow us to begin testing individual subsystems as soon as the hardware arrives.

A major milestone this week was ordering the development boards for the processor that we plan to use in the final system. Having the development boards on the way allows us to begin moving from theoretical estimates of processing capability and latency toward measurements on the actual hardware. In preparation for their arrival, we have started drafting several of the low-level drivers that will eventually be needed for the system. This includes planning the interfaces for peripherals such as I2C, I2S/SAI, DMA, timers, and other hardware needed to communicate with the audio codec and supporting components. Although these drivers cannot yet be completely validated without the target hardware, beginning them now should allow us to bring up the development boards more quickly once they arrive rather than starting the firmware from scratch at that point.

We also made progress on the custom hardware required to interface with several of our selected components. The breakout boards that we had been designing are now largely complete, allowing us to move closer to fabrication and physical testing. In particular, these boards will make it easier to prototype with components that would otherwise be difficult to connect directly to development hardware. Completing these designs represents another transition from system-level planning toward building and validating the actual electrical interfaces. Once the boards are fabricated and assembled, our immediate goal will be to verify power delivery and communication with each device independently before beginning full-system integration.

Another area we investigated this week was how firmware will eventually be programmed onto the processor once we transition away from the development board and onto our own PCB. To better understand how this is handled in an existing compact wearable product, we disassembled a commercially available headphone and examined how its internal electronics were laid out and accessed during manufacturing. This gave us useful inspiration for how programming and debugging interfaces can be incorporated into a small device without requiring a large permanent connector. It also helped us think more concretely about how our own PCB will transition from a development platform into hardware that can actually fit inside the final wearable.

Based on this investigation, we currently plan to use ST-Link and the STM32 SWD programming/debug interface for flashing the processor on our custom board. Rather than including a large header that would remain permanently attached to the final device, we plan to expose only the small number of connections required for programming and debugging. Our current concept uses approximately five wires for the ST-Link connection, providing the necessary programming, debugging, power-reference, ground, and reset connections. These wires can be attached during development and initial programming and then cut or removed once the board has been flashed and no longer requires a permanent programming connector. This approach should reduce the PCB area and physical volume required by the programming interface while still preserving convenient access during development.

The firmware architecture is also beginning to move from a high-level block diagram toward an actual implementation plan. Our previous work established that the ANC pipeline will rely heavily on DMA so that audio samples can continuously move between the codec and processor without requiring the CPU to manually handle every sample transfer. The processor can then operate on blocks of incoming samples while DMA simultaneously receives and transmits other blocks. With the development hardware now ordered, we can begin implementing the software infrastructure required for this architecture and eventually benchmark the actual interrupt frequency, DMA transfer timing, CPU utilization, and end-to-end latency. These measurements will be important because our previous research showed that latency is one of the most important constraints for achieving effective feedforward ANC.

We are also beginning to think more carefully about the progression of our hardware bring-up. Rather than immediately attempting to run the full adaptive ANC algorithm, we plan to validate the system incrementally. The first step will be confirming that the STM32 can communicate correctly with the audio codec and reliably receive and transmit audio using DMA. We can then test simple passthrough and fixed-filter processing before moving to the adaptive FxLMS implementation. This should make debugging significantly easier because problems involving the codec configuration, DMA transfers, timing, or signal processing can be isolated before they become part of a much larger system.

The physical teardown of an existing headphone also helped connect our electrical and mechanical design work. Previously, we had considered the size of the processor, codec, battery, microphones, and speakers primarily from datasheets and rough physical layouts. Seeing how a commercial headphone routes wires, distributes electronics, provides manufacturing access, and packages its PCB inside a limited enclosure gave us a more realistic reference for our own design. While our sleep-mask form factor is different from a conventional headphone, many of the same constraints apply, particularly minimizing rigid PCB area, avoiding large connectors, and ensuring that development interfaces do not unnecessarily increase the size of the final product.

Overall, the project is now moving from determining what we intend to build toward actually building and testing the subsystems required for the final device. Component selection and architectural decisions will still continue as necessary, but the development boards being ordered, breakout-board designs being completed, driver development beginning, and programming strategy becoming more concrete represent a significant transition into implementation. Our next major objective is hardware bring-up once the development boards and breakout boards are available. We plan to verify the basic STM32 peripherals, establish communication with the audio codec, test DMA-based audio transfers, and begin measuring the timing and computational performance of the audio-processing pipeline. These results will provide the first direct indication of how closely our earlier design assumptions match the behavior of the actual system and will guide the next stage of ANC implementation and hardware integration.

Team Status Report for 9/26

This week, our team focused on component selection, physical design, ANC research, and planning the firmware architecture for the system. We continued evaluating microphones, speakers, the audio codec, processor, battery, and supporting components based on latency, power consumption, physical size, cost, and compatibility with the overall system. We also began work on the ADAU1372 audio codec breakout and spent significant time considering how the microphones, speakers, electronics, battery, and heating components could physically fit into a comfortable sleep mask and headband.

A major focus this week was understanding how we will implement active noise cancellation in software. We researched digital feedforward ANC systems using the FxLMS algorithm, including an existing implementation that performs the adaptive processing on an STM32. That implementation uses DMA to acquire audio while the processor performs the adaptive computation, demonstrating that an STM32-based software implementation is feasible. We also learned that latency and physical geometry are particularly important. In a feedforward ANC system, the propagation time between the reference microphone and error microphone must provide enough time for the system to generate the cancellation signal.

From discussions during our project meetings, we identified software ANC as one of the main technical challenges and focuses of our project. ANC is often performed using dedicated hardware or specialized DSP systems, while our goal is to perform the adaptive processing ourselves on an STM32. This requires us to manage the audio transfers, filtering, coefficient updates, and real-time deadlines in software. We therefore began planning a firmware architecture that uses DMA for continuous audio transfers and an RTOS to coordinate the high-priority audio processing with slower system functionality. Our current design separates a fast audio processing loop from slower thermal, battery, and system control tasks.

We also spent time investigating whether memory would limit the length or quality of the adaptive filtering we can perform. We considered adding an external memory chip to support longer audio histories. After further research, we decided against this approach because ANC is primarily a streaming workload and does not require storing long sections of raw audio. Our current plan is to store small DMA buffers, filter coefficients, and the recent sample histories needed by the adaptive filters in the STM32’s internal SRAM. The expected working memory is much smaller than storing raw audio continuously, which would require roughly 768 kB per second for four channels of 48 kHz audio stored as 32-bit words. Avoiding external memory also helps us avoid introducing additional memory access delay into a system where low latency is important for cancellation quality.

Physical and mechanical design was another major area of discussion this week. We considered the locations of the reference microphones, error microphones, speakers, electronics, battery, and heating elements. These decisions affect both comfort and ANC performance. Our current concept uses outside-facing reference microphones to measure incoming snoring, error microphones near the ears to measure the remaining sound, and thin speakers near each ear to generate the cancellation signal.  We also considered how the mask and headband can remain comfortable during normal sleep and side-sleeping while keeping the acoustic components in sufficiently consistent positions.

The largest risk to the project is achieving useful ANC performance while performing the adaptive processing in software. CPU utilization, end-to-end audio latency, filter length, convergence behavior, and the physical acoustic paths can all affect cancellation quality. To manage this risk, we plan to first demonstrate ANC for a single ear on a bench setup before expanding to two ears and integrating the system into the wearable. We will first test the basic audio path and a simpler filter, then implement FxLMS and measure latency, attenuation, convergence, and CPU utilization. This approach lets us determine whether our processing platform is sufficient before adding the remaining complexity of the full wearable.

Our overall system requirements have not changed significantly this week, but our implementation strategy has become more concrete. We decided against adding external memory and are instead planning around a streaming architecture using internal SRAM, DMA, and real-time software. We also now consider software ANC implementation to be one of the primary technical contributions and risks of the project. We are currently generally on schedule, although ordering the remaining components soon is important to prevent hardware availability from delaying integration. During the next week, we plan to finalize and order components, continue the physical design, make progress on the ADAU1372 breakout, and begin implementing and benchmarking the real-time audio firmware.

Part A was written by May, Part B was written by Soma, and Part C was written by Josef.

Part A: Public Health, Safety, and Welfare (May)

Our product is intended to reduce disruptive snoring noise experienced by someone sharing a sleeping space with a person who snores. Reducing nighttime noise may improve the user’s sleeping environment and support both physiological and psychological well-being. Because the device will be worn near the user’s head for extended periods, safety is also an important design consideration. We need to ensure that the speakers cannot produce unsafe sound levels, the battery and electronics do not create electrical or thermal hazards, and the heating element cannot reach unsafe temperatures. The physical design must also remain comfortable and avoid pressure points or components that could create a hazard during sleep. We are therefore considering audio limits, battery protection, temperature monitoring, thermal cutoff mechanisms, and physical comfort as part of the design.

Part B: Social Factors (Soma)

Snoring can affect both the person who snores and other people who share the same sleeping environment. Persistent nighttime noise can disturb a partner’s sleep and may create tension when available solutions require the person who snores to wear a device or change their sleeping behavior. Our system instead gives the person affected by the noise greater control over their own sleeping environment. Users also have different sleeping positions, head shapes, comfort preferences, and sleeping arrangements, so the physical design must accommodate reasonable variation between users. These considerations have contributed to our focus on creating a compact and comfortable wearable that does not substantially interfere with either person’s normal sleeping routine.

Part C: Economic Factors (Josef)

Economic considerations have affected several of our technical decisions. Our system requires multiple microphones, speakers, an audio codec, a processor capable of real-time signal processing, power electronics, a battery, and mechanical components, so component cost must be considered alongside performance. For example, the official ADAU1372 evaluation hardware would consume a large portion of our approximately $600 project budget, which motivated our decision to pursue a simpler custom breakout for prototyping. We also decided against adding an external memory chip when our research indicated that the required filtering and buffering should fit within the STM32’s internal memory. Avoiding unnecessary hardware reduces both cost and system complexity. For a future production version, greater hardware integration and purchasing components in larger quantities could further reduce the per-unit cost.