Wavelength

Your world changes. Your hearing adapts.

Inspiration

One of our teammates wears hearing aids. During our initial brainstorming session, he showed us the companion app he uses to configure them. It was filled with sliders, settings, and adjustments that he has to revisit whenever his surroundings change.

That conversation changed the direction of our project.

For most people, moving from a quiet room into a crowded restaurant or walking outside onto a busy street happens without a second thought. But for someone who depends on hearing assistance, those transitions can mean constantly reaching for their phone, finding the right settings, and manually readjusting how they hear the world.

The technology is supposed to make everyday life easier. Instead, our teammate described having to repeatedly configure it just to feel comfortable in different environments.

We started asking a different question: What if your hearing aid could learn how you prefer to hear, instead of making you teach it the same preferences over and over again?

That question became Wavelength.

We wanted to explore hearing assistance as a continuously adapting system rather than a collection of static presets. A device that could observe changes in its acoustic environment, learn from occasional user corrections, and gradually reduce the need for manual adjustments.

More importantly, we wanted that intelligence to live on the device itself. Not behind a cloud API, not dependent on an always-connected smartphone, but on a resource-constrained microcontroller processing real-world audio.

What it does

Wavelength is an experimental, personalized hearing-assistance system that combines real-time digital signal processing (DSP), lightweight adaptive machine learning, and an embedded audio device.

Its central idea is simple: the user should not have to keep adapting to their hearing device. The device should learn to adapt to them.

Our design revolves around three interconnected capabilities:

Personalized Audio Processing: Wavelength uses frequency-dependent gain and digital signal processing to customize how incoming audio is transformed. Instead of applying identical amplification across the entire spectrum, the system supports individualized processing parameters that can emphasize or attenuate different frequency regions.

Environment-Aware Adaptation: Acoustic features extracted from incoming audio provide context about the surrounding sound environment. A lightweight adaptive model uses these features to select personalized processing settings, allowing the system to respond to environmental changes without requiring constant manual intervention.

Learning Through User Feedback: When the system makes an adjustment the listener does not prefer, the user can correct it. Those corrections become learning signals, helping Wavelength associate acoustic conditions with individual preferences. Over time, the goal is to reduce repeated adjustments in familiar listening situations.

A companion application provides an interface for calibration, configuring frequency responses, inspecting system behavior, and providing feedback. However, the intended architecture separates personalization from real-time operation: the STM32 handles audio processing and lightweight adaptation locally.

The long-term goal is a hearing device that becomes more personalized through use, while remaining under the listener's control.

Prototype demonstration: [INSERT VERIFIED DESCRIPTION OF WHAT THE DEVICE ACTUALLY DOES, INCLUDING WHICH ADAPTIVE FEATURES RUN ON THE STM32 AND WHICH REQUIRE THE COMPANION APP.]

Wavelength is a proof of concept, not a clinically validated or approved hearing aid.

How we built it

Wavelength combines embedded firmware, digital signal processing, adaptive learning, and a companion software interface.

Embedded Hardware — STM32

The system is designed around an STM32F411RE microcontroller, chosen as a resource-constrained platform for real-time audio processing.

Our hardware architecture uses digital microphone input, embedded audio processing, and an external digital-to-analog conversion stage for headphone output. The STM32F411RE does not contain an integrated audio DAC, so an external output interface is required.

[INSERT FINAL MICROPHONE CONFIGURATION, DAC/AMPLIFIER HARDWARE, CONNECTION DETAILS, SAMPLE RATE, AND WORKING AUDIO PATH.]

The objective is to perform audio processing locally rather than stream microphone audio to a laptop or cloud service.

Digital Signal Processing — C / CMSIS-DSP

The DSP pipeline is designed to support frequency-selective filtering and gain adjustment, creating configurable sound-processing profiles.

[INSERT IMPLEMENTED FILTER STRUCTURE, NUMBER OF FREQUENCY BANDS, BIQUAD CONFIGURATION, COMPRESSION OR LIMITING, BUFFER SIZE, AND ANY PERFORMANCE MEASUREMENTS.]

A second responsibility of the DSP pipeline is extracting lightweight acoustic features that the adaptive model can use to characterize the surrounding environment.

[INSERT ACTUAL FEATURES EXTRACTED AND HOW OFTEN THEY ARE UPDATED.]

Adaptive Intelligence — Lightweight Online Learning

Rather than relying on a large pretrained neural network, we focused on the problem of learning an individual's preferences from limited feedback.

The adaptive architecture is designed around a compact model that relates acoustic characteristics to preferred audio-processing parameters. When a user corrects the device's behavior, that feedback can update the model's predictions for similar conditions.

This creates a feedback loop between environmental observations, processing decisions, and user preferences.

The challenge is making that learning mechanism small and efficient enough to operate within the memory and computational constraints of a microcontroller.

[INSERT FINAL LEARNING ALGORITHM, INPUT FEATURES, OUTPUT PARAMETERS, UPDATE RULE, HOW USER CORRECTIONS WORK, AND WHETHER TRAINING/INFERENCE RUN ON THE STM32.]

[INSERT RESULTS FROM TESTS SHOWING WHETHER THE MODEL ACTUALLY LEARNS AND RECALLS PREFERENCES.]

Companion Application — Personalization and Control

The companion application is intended to make personalization more accessible without making the user dependent on constantly interacting with it.

It provides an interface for configuring sound-processing parameters, collecting feedback, and visualizing the system's behavior.

[INSERT ACTUAL FRONTEND FRAMEWORK, APPLICATION FEATURES, COMMUNICATION PROTOCOL, AND WORKING DEVICE INTEGRATION.]

The larger architectural goal is to let the companion application assist with calibration and more complex interactions while the embedded device remains capable of independent operation.

Challenges we ran into

Real-Time Audio Processing on Constrained Hardware

[DESCRIBE ACTUAL CHALLENGES WITH MICROPHONE INPUT, I²S CONFIGURATION, DMA, OUTPUT HARDWARE, AUDIO QUALITY, BUFFERING, OR LATENCY. EXPLAIN THE CAUSE AND HOW THE TEAM ADDRESSED IT.]

Designing Meaningful Adaptive Learning

[DESCRIBE HOW YOU CHOSE THE MODEL, DEFINED ACOUSTIC FEATURES, REPRESENTED USER PREFERENCES, AND BALANCED ADAPTABILITY AGAINST MEMORY AND COMPUTATIONAL LIMITATIONS.]

Integrating Embedded Systems and Application Software

[DESCRIBE REAL INTEGRATION PROBLEMS, INCLUDING SERIAL COMMUNICATION, SHARED DATA STRUCTURES, PROFILE UPDATES, OR COORDINATING FIRMWARE AND SOFTWARE DEVELOPMENT.]

Working Within Hackathon Constraints

[DISCUSS THE FEATURES YOU HAD TO PRIORITIZE OR REMOVE, THE TRADEOFFS YOU MADE, AND WHAT YOU LEARNED ABOUT SCOPING AN AMBITIOUS HARDWARE-SOFTWARE PROJECT.]

Accomplishments that we're proud of

[INSERT 3–5 VERIFIED ACCOMPLISHMENTS. PRIORITIZE FUNCTIONAL RESULTS OVER FEATURES THAT WERE ONLY PLANNED.]

Potential accomplishments to document if completed:

• Running real-time audio processing on the STM32 microcontroller.
• Implementing adjustable frequency-dependent processing.
• Developing a compact adaptive preference model.
• Demonstrating that user corrections influence subsequent predictions.
• Integrating the companion application with embedded hardware.
• Demonstrating that adaptive processing continues without an active application connection.
• Measuring and characterizing processing latency, memory usage, or adaptation accuracy.

What we learned

Wavelength pushed us to think across several disciplines that are often treated separately: embedded systems, signal processing, machine learning, and human-centered product design.

One of the most important insights behind the project is that personalization and adaptation are not the same thing. A device can offer dozens of settings and still force its user to manage all of them manually. Meaningful adaptation requires learning from previous interactions and applying that information appropriately as circumstances change.

We also approached machine learning from a different perspective. Instead of asking how large or sophisticated a model we could deploy, we asked what the smallest useful learning mechanism would be under strict memory, compute, and latency constraints.

[INSERT SPECIFIC TECHNICAL LESSONS FROM THE ACTUAL IMPLEMENTATION, INCLUDING WHAT FAILED, WHAT SURPRISED YOU, AND WHAT YOU WOULD CHANGE.]

Perhaps the most important lesson came before we wrote any code: understanding someone's actual experience with technology can reveal problems that are easy to overlook when designing a system from specifications alone.

Our teammate did not ask for more sliders, more presets, or a more complicated interface. He wanted to spend less time thinking about his hearing aids.

That became our guiding design principle.

What's next for Wavelength

Richer Environmental Understanding: Expand beyond simple acoustic features to distinguish more complex listening situations, including overlapping conversations, variable background noise, and changing sound sources.

More Efficient Preference Learning: Investigate contextual bandits, active learning, and uncertainty-aware adaptation to reduce the number of corrections needed before the system can reliably predict individual preferences.

Long-Term Personalization: Explore persistent on-device learning, allowing preferences to evolve over weeks or months while preserving user control and preventing unstable or unwanted adjustments.

Miniaturization and Power Efficiency: Move toward a smaller, lower-power embedded platform designed for practical wearable use.

Real-World Evaluation: Work with hearing professionals and interested users to investigate usability, individual preferences, and the limitations of adaptive processing. Any future medical claims would require appropriate acoustic safety validation and clinical evidence.

Our broader vision is not to replace established hearing aids overnight. It is to explore a different interaction model for hearing assistance—one where intelligent personalization reduces the burden of constant configuration.

Because the best hearing technology should help you experience the world, not make you constantly manage how you hear it.

Try it out

GitHub: [INSERT REPOSITORY URL]

Demo Video: [INSERT VIDEO URL]

Companion Application: [INSERT LINK IF AVAILABLE]

Technical Demonstration / Results: [INSERT SCREENSHOTS, MEASUREMENTS, OR DEMO DETAILS]

Built With

• adaptive-audio
• arm-cortex-m4
• c
• cmsis-dsp
• digital-signal-processing
• embedded-systems
• hearing-assistance
• human-in-the-loop
• i2s
• inmp441
• machine-learning
• online-learning
• real-time-audio
• signal-processing
• stm32
• stm32f411re