Posted on

Soma’s Status Report for 10/12 and or 10/17

This week, I focused on preparing our Hybrid LxFMS ANC algorithm for eventual integration with the embedded hardware. Our MATLAB simulation has already demonstrated promising noise attenuation, particularly in the lower-frequency range, so I began examining how the existing algorithm can be translated into an implementation suitable for real-time execution on the STM32. This involved reviewing the filtering operations, adaptive coefficient updates, and secondary-path modeling required by the algorithm while considering the computational and memory limitations of the embedded platform.

I also continued investigating the interaction between the physical acoustic configuration and the ANC feedback loop. Because the effectiveness of the algorithm depends heavily on the relative positions of the reference microphones, error microphones, and speakers, I looked further into how these components should be arranged within our wearable design. In particular, I considered how microphone placement and acoustic propagation delays could affect the ability of our system to generate anti-noise before unwanted sound reaches the user’s ears.

Alongside the algorithm work, I continued thinking about the physical construction of the wearable, including the integration of the speakers, microphones, and electronics into a comfortable sleep-mask form factor. My work is currently on schedule, although the final acoustic configuration will require experimental validation once the hardware is assembled. Next week, I plan to continue preparing the ANC implementation for embedded execution and begin developing a more concrete testing procedure for evaluating attenuation across different frequencies and microphone configurations.

Posted on

Josef’s Status Report for 10/12 and or 10/17

This week, I focused on moving our custom PCB designs closer to fabrication and preparing for the initial hardware verification process. With the breakout-board designs largely completed last week, I continued reviewing the schematics and layouts to ensure that the selected components could be reliably connected to our development hardware. In particular, I paid attention to power distribution, component footprints, signal routing, and the connections required to interface the audio codec with the STM32. The immediate objective is to fabricate and assemble these breakout boards so that we can begin testing individual components rather than relying entirely on datasheets and simulations.

I also continued investigating how our eventual custom PCB will accommodate programming and debugging without requiring large permanent connectors. Following our teardown of a commercial headphone, I explored the use of small exposed programming pads or temporary wire connections for the STM32 SWD interface. This would allow us to flash and debug the processor during development while keeping the final PCB compact enough to fit inside the wearable. I also considered how the board layout could minimize rigid areas and simplify connections between the microphones, speakers, battery, and processing circuitry.

Another area of focus was establishing a hardware bring-up procedure for the breakout boards once they arrive. This includes checking continuity, verifying power rails, confirming clock signals, and testing communication with individual components before connecting the full system. My work is progressing toward physical fabrication and assembly, although the functionality of the boards cannot be fully confirmed until they are manufactured and tested. Next week, I plan to continue fabrication and begin assembling and validating the first boards as soon as they become available.

Posted on

May’s Status Report for 10/12 and or 10/17

This week, I focused on beginning the implementation and bring-up of the embedded software that will run on our STM32 processor. With the development boards ordered, I began transitioning from planning the firmware architecture to implementing and testing the low-level functionality required for our ANC system. This included working on the processor’s clock configuration, basic peripheral initialization, and establishing a reliable workflow for programming and debugging the STM32 using ST-Link and SWD.

I also continued developing the DMA-based audio-processing infrastructure that will eventually connect the processor to our audio codec. Our current architecture uses a 48 kHz sampling rate with 64-sample processing blocks, so I focused on designing a double-buffered DMA system that allows audio transfers and computation to occur concurrently. I also began configuring the SAI/I2S peripheral and investigating the clocking and synchronization requirements of the codec. My immediate goal is to establish reliable audio input and output before introducing more computationally intensive filtering operations.

Additionally, I began considering how to benchmark the computational performance of the processor once the audio pipeline is operational. In particular, I plan to measure processing time per audio block, CPU utilization, DMA timing, and overall latency to determine whether our current architecture provides sufficient computational headroom for the Hybrid LxFMS algorithm. My work is currently progressing toward hardware validation, and next week I plan to continue peripheral bring-up and work toward establishing a complete audio passthrough pipeline.

Posted on

Team Status Report for 10/12 and or 10/17

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.

Posted on

Josef’s Status Report for 10/2

This week, I focused on understanding how we can transition our STM32 firmware from development hardware to the much smaller hardware required for the final wearable. As part of this work, we disassembled a commercially available headphone and examined how its internal electronics were packaged and accessed. This gave us a useful reference for compact wiring and connections, while also helping us consider how we can maintain access for firmware testing and debugging once the electronics are integrated into the mask.

One specific issue I investigated was how we will flash and debug the STM32 without the built-in programming interface provided by a development board. Based on our research, we decided to use an ST-Link through the STM32’s SWD interface. Our current plan is to expose the necessary programming and debugging connections using individual wires or small programming pads. During development, these connections will allow us to upload firmware, inspect program execution, and diagnose issues. The temporary wires can later be cut or removed once the firmware has been tested and the final device has been programmed.

I also continued considering the firmware and RTOS requirements for running the audio processing on the wearable. This includes planning how audio acquisition, processing, and output should be coordinated, and how task timing, buffering, and memory usage could affect the feedback loop. As we move toward implementation, maintaining reliable debugging access will help us evaluate these constraints on the final hardware. Over the next week, I plan to refine the programming and wiring approach and continue developing the firmware structure, with particular attention to RTOS task organization and meeting the timing requirements of the audio processing.

Posted on

Soma’s Report for 10/2

This week, I focused primarily on moving our custom hardware from the design stage toward implementation. I finished working on the breakout boards for several of the components that we will need to prototype the system, including preparing the designs so that we can begin fabricating and testing them. A major goal of these breakout boards is to allow us to test individual components independently before integrating everything onto a single custom PCB. This should make debugging significantly easier, particularly for components such as the audio codec where power, communication, and audio interfaces all need to be verified.

I also spent time considering how these breakout boards and development hardware will eventually translate into the final wearable design. As we move toward implementation, PCB size, connector placement, and accessibility for debugging are becoming more important constraints. We want the prototype hardware to remain easy to test while avoiding design decisions that would make the final system unnecessarily large.

My work is currently on schedule. Over the next week, I plan to begin designing the actual PCBs that will be used in the system, using what we learned from the breakout-board designs to guide component placement, routing, connector selection, and overall board size. The goal is to begin transitioning from temporary prototyping hardware toward boards that more closely reflect the form factor and electrical architecture of the final wearable.

Posted on

May’s Report for 10/2

This week, I focused on preparing the firmware side of the project as we transition from system design into implementation. Since we have now ordered the STM32 development boards that we plan to use for prototyping, I began drafting the low-level drivers and software infrastructure that will be needed once the boards arrive. This includes looking at the interfaces required for the audio codec and planning how peripherals such as I2C, SAI/I2S, DMA, and timers will be configured. Starting this work before the development boards arrive should allow us to begin hardware testing relatively quickly once we have access to the processor.

I also continued refining how the real-time audio pipeline will operate on the STM32. Our current architecture relies heavily on DMA to continuously transfer audio between the codec and processor while allowing the CPU to perform the ANC computation in parallel. One of the first goals after hardware bring-up will therefore be to establish a basic DMA-based audio passthrough system before implementing the adaptive FxLMS algorithm. This will allow us to measure the actual latency, transfer timing, interrupt overhead, and processor utilization of the platform.

My work is currently on schedule, and the main dependency is receiving the development hardware so that the drivers can be tested on the actual processor. Over the next week, I plan to continue writing the initial peripheral drivers and preparing a basic audio-processing framework. Once the boards arrive, I will begin validating the drivers and working toward a simple real-time audio input and output test before adding the full ANC processing.

Posted on

Team Status Report for 10/2

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.