⚠️ EXPERIMENTAL — NOT A MEDICAL DEVICE
OpenHear is a research platform and public build log, not a certified hearing aid.
Start at low volume, validate every configuration on your own hardware, and do
not treat any module in this repository as a substitute for clinical care.
OpenHear is a human sensory sovereignty platform — not a hearing aid, not a wellness device, not a consumer gadget. It is an open-source sovereign audio pipeline, haptic environment engine, therapeutic delivery layer, and future aids-free sensory system.
North star: human sensory sovereignty. The user decides what they hear, when they hear it, how they hear it, and what their acoustic environment does to their body and mind. The long-term configuration is still direct: no hearing aid, no behind-the-ear receiver, no bone conduction implant, no ear canal device of any kind. The wristband IS the hearing system. See Vision — Aids-Free Hearing below, the full eight-pillar platform architecture in docs/HUMAN_SENSORY_SOVEREIGNTY_ARCHITECTURE.md, and the aids-free subsystem document in .
The hearing aid industry charges £3,000–£8,000 for hardware, then locks you out of it.Your audiogram is a measurement of your body. It belongs to you.OpenHear gives it back.
Commercial aids from Phonak, Signia, and Starkey still ship with proprietary AI that mangles your own voice, whistles during hugs, and dies in sweat. Replacements cost £3,000–£8,000 and lock you into manufacturer fitting software. OpenHear is the sovereign alternative: an open-source DSP pipeline with adaptive feedback cancellation, own-voice bypass, and sweat-proof 3D-printed ITE shells you manufacture at home. Every algorithm is inspectable. Every parameter is yours. No cloud. No subscription. No lock-in. Licensed under Apache 2.0 with a Sovereign Use Addendum (see LICENSE).
What this is
OpenHear is an open-source human sensory sovereignty platform for people who are tired of factory AI, clinic gatekeeping, and environmental noise making decisions about their own senses without their consent.
It already works with aids you own and hardware you have. It is being extended into a wrist-native sensory system, a therapeutic haptic platform, a selective-hearing engine, and an acoustic privacy layer. It does not require an audiologist appointment to change a setting.
OpenHear is now both a software pipeline and a hardware concept. The pipeline gives you control over how your aids process sound. The hardware — the OpenHear Wristband (in development) — extends that control outwards into the environment itself, scanning for sounds your aids may not pick up and translating them into haptic awareness on the wrist. Software and hardware are unified by a single principle: the hearing aid user should have full sovereignty over how they perceive their acoustic environment.
OpenHear has nine pillars:
The OpenHear Wristband — active environmental intelligence
Aids-free architecture — the wristband as the complete hearing system
OpenHear gives people control over their own senses. It lets you choose what you hear, what you ignore, what your body learns from sound, and how your environment reaches you, whether you are deaf, hard of hearing, hearing, tired, stressed, training, sleeping, working, or simply wanting peace.
Tested on:
Phonak Naída M70-SP (Marvel platform)
Signia Insio 7AX (Augmented Xperience platform)
Required hardware:
Path 1 does not need this hardware. See START_HERE.md. Noahlink is only Path 2 (people who already own compatible aids and want to read their own fitting).
Noahlink Wireless 2 (~£80 on eBay)
Windows laptop (for fitting software)
iPhone or Android (for streaming)
OpenHear Wristband (in development) — continuous-wear haptic frequency scanner, pairs over Bluetooth with the rest of the pipeline. See the OpenHear Wristband section below.
The Burgess Principle
The Burgess Principle is the ethical and architectural root from which OpenHear grows. It is a framework, authored by Lewis James Burgess, for sovereign handling of clinical audiology data — audiograms, fittings, MPO calculations — so that a patient, a clinician, and a regulator can each hold an independent, verifiable, offline record of what was committed to and by whom, without depending on the cooperation of any vendor.
It rests on five commitments, enforced in this repository (see advocacy/gate.py, advocacy/adapters.py, and NOTICE):
Sovereign facts belong to the person they describe. The audiogram and fitting profile are facts about a human body and are never transmitted, bundled, or shared without that person's explicit, informed consent.
Every clinical commitment is cryptographically verifiable. A SHA-256 commitment over a canonical serialisation of the facts is the only value intended to leave the device, and any party holding the bundle can verify it offline with no vendor involvement.
Trust is binary: SOVEREIGN or NULL. A real human personally reviewing the specific facts and signing a receipt produces SOVEREIGN; pure automation, blanket policy, an invalid signature, tampering, or a refusal to engage produces NULL. There is no third state.
Raw audio is not a clinical fact. Any attempt to commit bytes, bytearray, memoryview, or a NumPy ndarray into a facts payload raises RawAudioRejectedError before a commitment is produced.
Schema ownership is singular. The openhear-advocacy-v1 schema family is owned by this repository; integrators do not fork, re-version, or extend it.
The advocacy layer in this repository is the reference implementation of these commitments. The next layer — Iris, an AI companion built within the Burgess Principle — will provide a higher-level advocacy workflow post-1.0.0. Iris will import OpenHear; OpenHear will not import Iris. An integration that satisfies the five commitments today will be compatible with Iris automatically.
Modern hearing aids are extraordinary pieces of engineering. They are also, deliberately, black boxes.
When you buy a Phonak or Signia aid, you get a device that:
Constantly reclassifies your acoustic environment without telling you
Applies compression, noise reduction, and beamforming algorithms you cannot inspect
Stores your audiogram and fitting profile in a proprietary format you cannot read
Requires a registered audiologist and £200+/hr of fitting time to adjust a single parameter
Reverts to factory defaults if the fitting software version doesn't match
This is not a safety requirement. It is a business model.
The audiogram stored in your hearing aids is a biometric measurement of your nervous system. The fitting profile is a record of how your brain processes sound. You generated that data. You wore the sensors. You sat in the booth.
It is yours.
What OpenHear does
World → Microphone → Custom DSP Engine → Bluetooth Stream → Your Aids → Your Ears
Core module — reads your existing fitting data out of your aids via Noahlink Wireless. Exposes it as plain JSON. No proprietary format, no locked PDF.
DSP module — real-time Python audio pipeline. You control the compression curve, the noise floor, the beamforming angle, the voice frequency emphasis. Tuned to your audiogram, not a population average.
Stream module — sends processed audio directly to your aids over Bluetooth. No extra hardware. Works on iPhone and Android.
Audiogram module — reads, visualises, and exports your hearing thresholds in open formats. The data your audiologist has been keeping in a system you can't access.
Learn module(Phase 6) — a local preference engine that adjusts to your own corrections over time. Listener A/B choices are captured by learn/preferences.py, folded into deterministic config suggestions by learn/engine.py, and recalled per environment via the saved profiles in learn/profiles.py. Your hearing profile improves every day, not once every two years.
OpenHear Wristband — Active Environmental Intelligence
The pipeline above improves the sound that already reaches your aids. The wristband does something different: it scans the environment in parallel, on the wrist, and tells you about sounds your aids never delivered — or sounds you weren't oriented toward.
It is a continuous-wear device designed to work alongside hearing aids, not replace them. Passive amplification becomes active environmental intelligence.
World → Wrist Microphone Array → On-device AI Classifier → Haptic Motor Array → Your Wrist
↕
Bluetooth
↕
Aids · Phone · Pipeline
Edge AI sound classification — low-latency on-device inference identifies environmental sounds in real time. Nothing is sent to a cloud. Your environment is your data and it stays on the wrist. The same sovereignty principle that governs your audiogram governs every sample the wristband hears.
Multi-motor haptic feedback — an array of small motors arranged around the wrist creates a spatial sound field through haptic patterns. Different sound classes, directions, and frequency bands have distinct haptic signatures. You build a physical sense of your acoustic surroundings without relying solely on what your aids decide to amplify.
Directional awareness through haptic mapping — the wristband communicates not just what a sound is but where it is coming from. Motor positions map to compass points around the wrist, so a siren behind you, a voice to your left, and a doorbell in front feel distinctly different. This is spatial awareness for sounds the aids may not be picking up or that you simply aren't oriented toward.
Bluetooth connectivity — pairs with hearing aids, smartphones, and smart home systems. Speaks the same protocols as the rest of the OpenHear pipeline so the wristband, the aids, and the DSP module act as one unified system rather than three separate devices.
Personalised AI models — the classifier adapts to the user's specific environment over time. A user in a barbershop has different priority sounds to a user in an office; the model learns the difference and adjusts haptic responses accordingly, with no manual configuration. Adaptation happens locally on the device.
Proactive frequency-specific scanning — instead of reacting after a sound has occurred, the wristband actively scans the frequency spectrum and alerts you to sounds approaching your detection threshold before they become relevant. Environmental sonar, not environmental amplification.
How it relates to existing devices
The collaboration enquiry that prompted this work came from Sharp Hearing, a UK audiology clinic that already features the Neosensory Buzz on their site — a basic haptic wristband that converts sound into vibration patterns. The OpenHear Wristband goes significantly further:
Capability
Neosensory Buzz
OpenHear Wristband
Sound → vibration
✓
✓
On-device AI sound classification
—
✓
Directional haptic mapping (compass points on the wrist)
—
✓
Proactive frequency-specific scanning
—
✓
Personalised models that adapt to your environment
—
✓
Pairs into a sovereign open-source DSP pipeline
—
✓
Local-only — no cloud, no telemetry
partial
✓
Why this fits OpenHear
The developer wears Phonak Naída and Signia aids. The gap the wristband fills is one lived every day: aids amplify what reaches the microphones in front of your ears, in the direction you happen to be facing, within the frequency response the manufacturer chose. Everything outside that envelope is silence. The wristband closes that gap on the wrist, under the user's control, with the same data-sovereignty guarantees as the rest of the project.
OpenHear Vision — The Wristband as the Hearing System
The wristband section above describes a companion device. This section describes where the architecture is going.
The long-term vision is direct: the wristband stops being a companion and becomes the hearing system. It captures the environment, classifies it, processes it against your audiogram, and transmits a finished audio signal to a minimal receiver worn at the ear. The £3,000–£8,000 behind-the-ear black box — with its proprietary firmware, locked fitting software, and audiologist-gated parameters — is no longer required. It is replaced by a piece of jewellery on the wrist and a passive driver at the ear.
The architecture — three layers, one user
World → Wrist Mic Array + Hearing NPU → Wireless Link → Bone Conduction Receiver / Open-Fit Earbud → Cochlea
[capture + classify + process] [low-latency] [deliver only]
Layer 1 — Wrist (sensor and processor). The wristband carries the microphone array, the hearing-specific neural processing unit, the audiogram, and the DSP pipeline. All of the intelligence of the system lives here, on the user's wrist, where it can be charged, updated, inspected, and replaced independently of anything worn at the ear.
Layer 2 — Wireless transmission. A low-latency link between the wrist and the ear-worn receiver. Sub-5ms end-to-end is the target. Standard, open, and inspectable — no proprietary radio that locks the receiver to a single vendor.
Layer 3 — Ear (delivery only). A minimal behind-the-ear bone conduction receiver, or an open-fit earbud, whose only job is to convert the finished signal into vibration or sound. No microphones. No classifier. No DSP. No firmware that does anything other than receive and drive a transducer. When it breaks, you replace a £30 part, not a £6,000 one.
A hearing-specific NPU — designed for this and only this
The processor on the wrist is not a general-purpose AI chip with a hearing application bolted on top. It is a neural processing unit designed from first principles for one task: real-time, personalised hearing.
Sub-5ms end-to-end latency — capture to ear. Anything slower is felt as delay during conversation.
Personalised audiogram-based DSP — compression curves, frequency shaping, and feedback cancellation derived from your thresholds, not a population fit.
On-device classification and beamforming — environmental scene analysis and spatial steering run locally, at the same latency budget as the DSP itself.
Performance targets that exceed current hearing aid SoCs — at a fraction of the silicon cost, because the chip does one job extremely well rather than every job adequately.
A general-purpose chip repurposed for hearing will always lose to a chip that was drawn for hearing. We intend to draw the chip.
Sovereignty extended to hardware
OpenHear already gives the user sovereignty over their audiogram, their fitting data, and the DSP algorithms that act on them. The wristband-as-hearing-system extends that sovereignty down to the silicon and out to every device worn on the body.
No proprietary firmware at any layer of the stack — wrist, link, or receiver.
No locked fitting software. The audiogram lives on the wrist as plain JSON. Adjusting a parameter means editing a value, not booking an appointment.
No audiologist gatekeeping. Audiologists are welcome as collaborators and clinicians; they are not required as a key to your own hearing.
No vendor lock between layers. The receiver at the ear is interchangeable. The wristband is interchangeable. The link is an open standard. The user owns every layer.
The hearing aid industry's business model depends on the user not being able to see inside the device. This architecture is the device with the lid removed.
Regulatory pathway
The system enters the world as a companion device — running alongside existing hearing aids, augmenting them, doing nothing the aids themselves do. This is the position the current OpenHear pipeline and wristband already occupy and it requires no clinical claim to be made.
The standalone configuration — wristband plus bone conduction receiver, replacing the hearing aid entirely — is the longer pathway. The regulatory target for the standalone device in the United Kingdom is UK MDR 2002 Class IIa, the same classification carried by conventional air-conduction hearing aids. Clinical evidence accumulates first; the claim follows.
Collaboration
Open source hardware and open source software, end to end. Schematics, RTL, firmware, DSP, and fitting tools all under permissive licenses. Specifically invited:
Audiologists — clinical input on fitting protocols, validation, and the standalone regulatory pathway.
Chip designers — architects and RTL engineers interested in a hearing-specific NPU built from first principles.
DSP engineers — compression, beamforming, feedback cancellation, and own-voice detection at sub-5ms latency budgets.
Hearing aid users — the people the system exists for. Lived experience is a design input, not a marketing line.
Industry & Institutional Engagement
Industry engagement (active, July–August 2026)
Commercial integration conversations are active with multiple wellness technology and assistive device companies. The discussions cover acoustic environment classification, haptic rendering, and the governance wrapper.
The commercial model is COSS (Commercial Open Source Software): the open core (Apache 2.0) is permanently free; the governance layer (UK Certification Mark UK00004343685) is licensed commercially per device at scale. A formal term sheet for a two-phase integration partnership — Phase 1 technical evaluation, Phase 2 paid integration pilot — has been prepared and is in circulation.
Sharp Hearing (US audiology clinic) is recorded as the first formal industry contact, 20 April 2026.
Institutional partnerships (active)
Health Innovation North East and North Cumbria (HI NENC), funded by the UK Office of Life Sciences — Innovation Pathway ref 1643. A market analyst is conducting competitive landscape research across seven sections: competitor analysis, NHS landscape, regulatory pathway, patent/prior art, market sizing, pricing, and evidence base.
RNID (Royal National Institute for Deaf People) — confirmed participant recruitment from the Research Panel (~1,600 members, ~1,100 hearing aid users) launching 12 August 2026. Innovation Seed Fund application planned November 2026.
UK Information Commissioner's Office — IC-501417-W5W9: the ICO found Sonova/Phonak's response to a Subject Access Request regarding AutoSense OS algorithmic accountability inadequate (outcome letter 31 July 2026) and is writing to Sonova directly.
MHRA — CEC 253215: medical device safety concern regarding AutoSense OS automated clinical decision-making; FOI2026/00527 internal review requested regarding DSAR reclassification and substantive regulatory questions.
Regulatory and academic record
UK Certification Mark UK00004343685 accepted 21 July 2026, published in Trade Marks Journal 24 July 2026, opposition period to 24 September 2026.
7 papers publicly distributed on SSRN (author page: per_id=11571908); lead paper: The Burgess Test v2.1 (SSRN 6759778).
First judicial validation: TPT DK00003-2605 ALLOWED, 14 June 2026.
Accessibility profiles (v1.4.0+)
Optional, user-declared accessibility profiles are shipped for cerebral palsy, autism, and sensory-processing needs. In the live wristband path they damp non-safety haptics, configure a firmware-enforced gradual onset, raise the confidence gate, and widen alert spacing; cerebral palsy also supplies hold-to-confirm and dysarthria-tolerant voice defaults. Alarm delivery remains subject to its perceptibility floor. Nothing is detected, inferred, stored, or transmitted. See accessibility/README.md.
OpenHear Vision 2 — Aids-Free Hearing: the wristband IS the hearing system
The previous section described removing the £3,000–£8,000 behind-the-ear processor and keeping only a minimal ear-worn receiver. This section goes one further. It removes the receiver too.
There is no hearing aid in this system.
There is no behind-the-ear receiver.
There is no bone conduction implant.
There is no ear canal device of any kind.
There is a wristband, a personal model, an audiogram, and a brain trained to read them. The user owns all four.
Mechanism of action — sensory substitution, not amplification
OpenHear's standalone configuration is not a hearing aid by mechanism. It is a somatosensory hearing substitution device. Sound is captured at the wrist, classified by edge AI, weighted against the user's audiogram, and rendered as a high-resolution multi-frequency haptic field on the skin. The brain — through documented neuroplasticity, going back to Bach-y-Rita's 1969 tactile-vision substitution work — learns to read that field as auditory information.
This is the same class of device as the Neosensory Buzz, but with an order of magnitude more channels, true frequency-rich spatial encoding, audiogram-weighted band synthesis, and an open silicon and open RTL stack. It is not a hearing aid. It does not claim to restore cochlear function. It substitutes for it.
Skin as the transducer
The volar wrist carries Pacinian, Meissner, Merkel and Ruffini mechanoreceptors covering roughly 5 Hz – 1 kHz of perceivable mechanical drive. Audio above this band is encoded — into motor position, drive pattern, and temporal structure across the array — not transmitted as raw vibration. Target actuator pitch is 8–12 mm, deliberately tighter than two-point discrimination, exploiting funnelling and apparent-motion illusions to produce a perceived spatial resolution finer than the physical receptor field.
Minimum viable: 24 actuators in a single ring (Neosensory-class density).
Target v1: 64 actuators in a 4-ring × 16-column lattice covering the wrist.
Aspirational v2: 128 actuators extending up the forearm, enabling a 2D haptic "screen".
Neural adaptation — open protocol, user-owned data
Adaptation is the design target, not raw signal fidelity. The training pipeline is published as a five-phase open protocol — calibration, phoneme sandbox, words and environment, open conversation, spatial and extended-spectrum — running on a cross-platform companion app. All data lives on the user's device as plain Parquet. There is no cloud account.
The Phase 3 progress file stores only derived metadata for passive wear and
active-recall checks. It does not store raw audio, waveforms, speaker identity,
or cloud identifiers, and it is experimental telemetry rather than clinical
evidence.
Phase 4 adds a local-only scaffold for spatial and extended-band training:
The Phase 4 progress file stores only derived localisation, extended-band,
timing, environment, rating, and outcome metadata. It does not store raw audio,
waveforms, location traces, biometric identifiers, cloud identifiers, or
clinical claims.
Phase 5 — Sovereign Device bundle
Phase 5 is the local, one-click bridge from an audiogram to a self-contained
device build. It generates firmware plus a sovereign build manifest from a
openhear-audiogram-v1 JSON file, with no network dependency and no raw audio:
python -m hardware.sovereign_device.pipeline AUDIOGRAM.json ./build --ear right
The manifest records firmware, audiogram, and component-database hashes,
safety requirements, regulatory status, and cost-target status without
embedding the underlying audiogram thresholds. Full plan and exit criteria
are in docs/PHASE5_SOVEREIGN_DEVICE.md.
A Hearing NPU, designed from first principles
A general-purpose mobile SoC running PyTorch Mobile cannot meet the latency or power budget. The Hearing NPU is designed for one job: continuous, personalised, low-latency hearing-as-haptics.
Stage
Latency budget
Mic capture + ADC
0.3 ms
Front-end DSP (beamform, AEC, VAD)
0.7 ms
Bark-band analysis (FFT/filterbank)
0.5 ms
Audiogram weighting
0.1 ms
Classification + scene tag
1.5 ms
Haptic render (mapping + envelope)
0.6 ms
Motor driver chain
0.8 ms
Mechanical rise time (LRA/piezo)
0.5 ms
End-to-end target
≤ 5 ms
ISA: RISC-V RV32IMC + RVV 1.0 (open ISA, open implementations).
Accelerator: 8 × INT8/INT4 MAC tiles at ~2 TOPS, hardwired bark filterbank, single-cycle audiogram lookup, deterministic haptic scheduler.
SRAM-only data path: 4 MB on-die, no DRAM. The model lives entirely on chip; this is the architectural reason ≤ 5 ms is achievable.
Power envelope: 80–120 mW continuous, < 5 mW idle.
Open RTL under CERN-OHL-S. No proprietary IP in the data path.
Until tape-out, the staged hardware path is: v0 on Raspberry Pi CM4 + Hailo-8L (~30 ms latency, sufficient for adaptation studies) → v0.5 on a RISC-V SBC + Coral Edge TPU (~15 ms) → v1 FPGA validation on Lattice ECP5 with the open RTL (~5 ms) → v1 ASIC at 22 nm FD-SOI.
Beyond hearing — capabilities a hearing aid cannot have
Once sound is decoupled from the ear and rendered as multi-channel haptics, the system trivially extends past biological limits.
Ultrasonic (20–96 kHz with appropriate MEMS) — bat activity, leak detection, dog whistles.
Full-sphere spatial awareness — azimuth via beamformer, elevation via ring index, distance via envelope decay. Above and below the wearer, which biological hearing handles poorly.
Multi-source separation — render two simultaneous speakers to two distinct regions of the wrist, allowing the wearer to "listen" to both in parallel.
Persistent acoustic memory — last 30 s ring buffer, replayable on demand to the haptic field.
Contextual silencing — known irritant classes attenuated by the classifier, not by global compression.
Biological hearing is a 20 Hz – 20 kHz omnidirectional pressure sensor with poor elevation discrimination and no scene understanding. OpenHear, on the wrist, is none of those things and all of the things they cannot be. The aids-free configuration is superior, not equivalent.
Any captured audio — opt-in only, encrypted with a key the user holds.
Enforcement is not a policy promise; it is built in:
The NPU has no IP stack. There is no network egress in the hearing data path.
Firmware is signed, but the signing key is the user's. A user can sign and load their own firmware. (This is the inverse of the hearing aid industry's lock-down.)
Plain-file formats end to end — JSON, Parquet, ONNX, WAV. No proprietary container.
Every parameter an audiologist would set in proprietary fitting software is a writable field in profile.json. Audiologists are welcome collaborators; they are not a key.
Regulatory pathway — sensory substitution, not hearing aid
Regulatory classification follows mechanism, not indication. The aids-free OpenHear has the same mechanism as Neosensory Buzz and BrainPort, both of which are cleared as sensory substitution devices, not hearing aids.
Jurisdiction
Likely classification
Comparator predicate
UK (MHRA)
UK MDR 2002 — Class I (initial), Class IIa if claims tighten
Neosensory Buzz
US (FDA)
510(k) Class II, sensory substitution
Neosensory Buzz, BrainPort Vision Pro
EU (MDR)
Class I or IIa under MDR 2017/745
Same
The fastest credible path: bench validation in months → single-user adaptation log (publicly, by the developer) → multi-user pilot (n≈20) in year 1 → controlled trial in year 2 → submission in year 3. Open data at every stage.
Open hardware path
Schematics: KiCad 8 wristband package planned for a future hardware/wristband/ directory; not yet committed in this repo.
RTL: Verilog/SystemVerilog Hearing NPU package planned for a future hardware/npu/ directory; not yet committed in this repo.
Mechanical: FreeCAD/OpenSCAD wristband CAD planned for a future hardware/wristband/mech/ directory; not yet committed in this repo.
BOM: globally-available distributors only; no single-source critical parts.
Targeting OSHWA certification at v0 and a Hackaday Prize / Open Hardware Summit submission.
Specifically invited
Mechanoreceptive psychophysicists — for Q1 (information bandwidth of the wrist) and Q4 (calibration protocol) of the research roadmap.
Sensory-substitution neuroscientists — for Q2 (adaptation timeline) and the cortical remap evidence base.
RISC-V RTL engineers — for the Hearing NPU.
Embedded DSP engineers — for the sub-5 ms front-end and haptic renderer.
UK / EU / US audiology clinicians — for the multi-user pilot and the regulatory pre-submissions.
Deaf and hard-of-hearing wearers — the people the system exists for. Lived experience is a design input, not a marketing line.
The longer this section gets, the closer the architecture is to leaving the page. The architecture document and roadmap are both in this repo. Read them; fork them; contradict them; submit a PR.
The three pain points this solves
Problem
Factory behaviour
OpenHear behaviour
Voices sound unnatural
AutoSense OS reclassifies constantly, smears transients
Linear mode + tunable WDRC compression
Constant unwanted adjustments
Environment AI fires every few seconds
You are the AI
Too much background noise
Fixed factory noise floor
Tunable beamforming, adjustable noise gate
Philosophical foundation
OpenHear is built on the Burgess Principle (summarised above and stated in full in docs/BURGESS_PRINCIPLE.md) — the position that data generated by or about your body belongs to you and not to the institution that measured it, and that any clinical commitment about your body must be independently verifiable, offline, by anyone holding the bundle.
The advocacy layer in this repository is the reference implementation of that principle. The principle in turn sits within a wider body of work on data sovereignty by the same author, including the legal framing repository on void ab initio against bulk-processed warrants and tainted data records.
OpenHear applies the principle directly to audiological data:
Your audiogram was generated by measuring your auditory nerve response. It is yours.
Your fitting profile was created by adjusting parameters until your perception was satisfied. It is yours.
The Noahlink Wireless is your key. The open standard is your right. The algorithms are yours to read, copy, modify, and improve.
See SOVEREIGN_AUDIO.md for the full framework.
Getting started — three paths
Path 1 — Quick start (phone + existing aids)
Install the experimental OpenHear Android scaffold from /mobile/ — see mobile README for the current skeleton-only status
Load your audiogram JSON (export from your audiologist or create one using audiogram/data/FORMAT.md)
Pair your aids via Bluetooth Classic or ASHA
Tap ▶ once you have verified the current mobile build supports the stages you need on your device; the Android app is an active public prototype, not a finished clinical tool
Set your aids to linear mode (kill the factory AI — see instructions below)
pip install -e . (editable install using the new pyproject.toml)
or pip install -r requirements.txt for the legacy flow
python -m core.read_fitting — exports the current raw Noahlink payload to JSON; add --session to emit the new structured FittingSession format and --verbose for DEBUG logging
python -m dsp.pipeline — starts the real-time audio processor. Useful flags: --bypass for A/B, --test-tone when no mic is plugged in, --latency for per-block latency logs, --metrics-csv metrics.csv to record CPU / RMS / latency
Copy examples/config.yaml to ~/.openhear/config.yaml and tune it (see docs/TUNING_GUIDE.md); dsp/config.py defaults still work as a fallback
Optional — exercise the aids-free training scaffolds with
python -m stream.phase2_training,
python -m stream.phase3_open_conversation, and
python -m stream.phase4_spatial_extended; build a sovereign-device bundle
with python -m hardware.sovereign_device.pipeline AUDIOGRAM.json ./build
audiogram-weighted intensity scaling from either the current v1 format or the legacy OpenHear v0.1.0 JSON export
BLE UART transport to a micro:bit advertising as OpenHear
patient safety defaults that bias toward the worst ear when one intensity byte must represent both ears
The v1.0.0 clinic prototype keeps Noahlink extraction on a separate hardening
track: the wristband already accepts audiogram JSON, while direct parsing in
core/read_fitting.py and audiogram/reader.py still contains placeholder
frame parsing that needs real-device confirmation.
To keep a running development memory inside the repository, use:
models/ — base classifier, separator, and personal-LoRA scaffold
training/protocol/ — Phase 0–4 training app and metrics (Phases 2–4 currently scaffolded under stream/phase{2,3,4}_*.py; Phases 0–1 still pending)
v0 prototype on Raspberry Pi CM4 + Hailo-8L + 24-LRA wrist sleeve
v0.5 prototype on RISC-V SBC + 64-piezo lattice
v1 FPGA validation on Lattice ECP5
FDA Q-Sub and MHRA Innovation Office pre-submission
Multi-user adaptation pilot (n≈20) with a UK academic audiology partner
OpenHear expansion — nine pillars
The pipeline, hardware work, and roadmap above remain in force exactly as written. What follows is the expansion: OpenHear as a human sensory sovereignty platform spanning nine explicit pillars.
Pillar 1 — The OpenHear Wristband: Active Environmental Intelligence
The OpenHear Wristband is a continuous-wear frequency scanner designed to work alongside existing hearing aids now and make them unnecessary later. It converts passive amplification into active environmental intelligence.
Edge AI sound classification — low-latency on-device AI identifies and classifies environmental sounds in real time, entirely locally. No cloud. No telemetry. No data leaving the wrist.
Multi-motor haptic array — an array of motors creates a spatial sound field through distinct haptic patterns. Different sounds, directions, and frequencies become different signatures on the skin.
Directional awareness through haptic mapping — the wristband tells the user not just what a sound is but where it is coming from, using compass-point mapping around the wrist.
Bluetooth LE Audio connectivity — the wristband pairs with existing hearing aids, smartphones, Apple Watch, and smart home systems, integrating directly with the OpenHear DSP pipeline.
Personalised adaptive AI models — the classifier learns the user's actual environment over time. A barbershop, a stadium, a concert hall, a surgery, and a nursery do not sound the same and should not be treated the same.
Proactive frequency scanning — the wristband actively scans the spectrum and warns about sounds approaching detection threshold before they become relevant. Environmental sonar, not environmental amplification.
Sharp Hearing (US audiology clinic, 20 April 2026) is the first formal industry contact recorded for this direction. As of July–August 2026, commercial integration conversations are active with multiple wellness technology and assistive device companies, and institutional partnerships are in place with HI NENC, RNID, the ICO, and MHRA. See the Industry & Institutional Engagement section above for the current state.
Pillar 2 — Aids-Free Architecture: The Wristband as the Complete Hearing System
The wristband is not permanently a companion to hearing aids. It is the first step toward a full system in which no hearing aid, no behind-the-ear receiver, and no ear canal device of any kind is required.
The wristband captures environmental sound via microphones, runs edge AI classification, and processes the full signal on-device.
A dedicated hearing-specific neural processing unit is designed from first principles for this task, targeting sub-5 ms end-to-end latency from environmental sound capture to haptic output.
Somatosensory substitution becomes the delivery path: the skin carries structured auditory information and the brain learns to read it.
Where a minimal early receiver is useful, the system supports a coin-sized bone-conduction transducer behind the ear, driven wirelessly from the wristband, with no ear canal blockage and no clinic-gated fitting lock.
The hardware stack is open from chip level upward: RISC-V, custom FPGA validation, and community-contributed hardware designs.
The regulatory path starts as a companion device beside existing aids. Classification is not asserted here. See docs/INTENDED_PURPOSE.md.
Pillar 3 — Peak Hearing for All Users
OpenHear is not only for people with hearing loss. It treats peak childhood hearing as the baseline reference and rejects progressive acoustic decline as an unchangeable fact of adult life.
Hearing users get restoration and extension of sensitivity lost over time.
Deaf users get full sensory access for the first time through open, trainable substitution pathways.
Children get support for peak auditory development and earlier drift detection before conventional diagnosis.
Athletes and performers get acoustic acuity beyond what biological hearing and training alone can deliver.
The training protocol, adaptation timelines, onboarding flows, and community training programmes are open source and user-owned.
Pillar 4 — Selective Acoustic Sovereignty
OpenHear does not just help the user hear more. It gives the user complete control over what enters consciousness. The acoustic environment is no longer something that happens to the user; it is something the user configures.
Required focus modes
Crowd filter — preserve coach, teammate, referee, or foreground conversation while the crowd drops away.
Concert mode — keep the performance, attenuate chatter, bar noise, and venue distortion, and reconstruct the optimal listening position regardless of where the user is standing.
Deep focus — maximise clarity for one voice or one task while reducing environmental load and tracking cognitive benefit through HRV correlation.
Situational awareness — maximise environmental intelligence, classification, and spatial mapping for cyclists, runners, parents, and public-space safety.
Sleep mode — attenuate traffic, neighbours, and irrelevant noise while preserving the user's child, their alarm, or a specific critical alert tone.
Performance mode — profession-specific acoustic profiles for surgeons, pilots, musicians, athletes, dispatchers, and anyone whose work depends on hearing specific cues.
Privacy mode — directional microphone nulling, acoustic fingerprint masking, and environmental sound signature anonymisation so the user controls not only what they hear but what the environment reveals about them.
The Acoustic Profile Store is an open community repository of acoustic profiles: forkable, shareable, reviewable, and governed like code rather than an app store.
Pillar 5 — Therapeutic Frequency Delivery: 30 to 300 Hz
OpenHear uses the same wristband as a programmable therapeutic delivery surface across the 30-300 Hz range, either alongside hearing substitution or independently of it.
40 Hz gamma stimulation — anchor protocol for cognitive and neural-entrainment research.
Whole-body vibration adjacency — lower-frequency recovery and regulation patterns translated into a wrist-safe, continuous-wear format.
Skin and connective tissue stimulation — 30-100 Hz protocols for collagen, elasticity, and dermal repair research.
Athletic recovery — post-exercise delivery windows for muscle repair and inflammation management.
Personal evidence building — HealthKit and Android Health Connect log HRV, sleep quality, activity, and skin conductance so the user builds their own evidence base locally.
Therapeutic scheduling integrates with Apple Watch and Wear OS sleep-stage detection so timing is phase-aware, measurable, and user-owned.
Pillar 6 — iOS and Android Native Integration
Apple and Android devices are not a bolt-on companion. They are the first infrastructure layer for OpenHear's mobile runtime.
Apple stack — Neural Engine, Core Haptics, Core Audio, HealthKit, Core Location, Maps, Spatial Audio, Apple Watch, ARKit, Shortcuts, and Automation.
Android stack — TensorFlow Lite, NNAPI, Oboe, Health Connect, advanced haptic APIs, Google Maps Platform, Wear OS, and assistant integrations where the user wants them.
Location-triggered profile switching — entering a barbershop, stadium, nursery, theatre, office, or concert hall automatically activates the right acoustic profile.
Open SDK — third-party developers can build OpenHear-compatible applications without routing user data through a central company server.
All health data stays on-device and inside the user's own health record. There is no platform lock-in and no mandatory vendor cloud.
Pillar 7 — Emotional and Cognitive Acoustic Intelligence
OpenHear learns how sound affects this specific user, not a statistical average of other people. Apple Watch and Android wearables provide the biometric substrate; OpenHear keeps the model local and the decisions explainable.
Detect dropping HRV and automatically shift acoustic profile to attenuate stressors and optionally introduce therapeutic frequencies.
Learn that crowd noise, transport hubs, or certain venues are physiologically stressful for this user and intervene before overload arrives.
Distinguish positive arousal from negative arousal so a concert high is not treated like commuting stress.
Keep all correlation data on-device in the user's HealthKit or Health Connect record plus local model storage the user can inspect, export, or delete.
Pillar 8 — Social Acoustic Layer
OpenHear users should be able to share acoustic meaning, not just settings.
Shared acoustic presence — two users in different places experience the same acoustic profile simultaneously.
Haptic communication — a new non-verbal channel built from user-owned haptic vocabulary. A squeeze can mean “I am here.” A rhythm can mean “pay attention.” A burst can mean “I love this moment.”
Community acoustic mapping — venues, transport hubs, parks, streets, and public spaces become annotatable for acoustic accessibility, safety, and therapeutic quality.
Accessibility ratings surfaced through maps — contributed anonymously, verified by community consensus, and never dependent on uploading raw audio.
Pillar 9 — Beyond Biological Hearing
With peak childhood hearing as the baseline, OpenHear moves into augmentation.
Ultrasonic detection — 20 kHz to 100 kHz translated into haptic patterns for machinery signatures, structural monitoring, and signals no unaided human has ever perceived.
Infrasonic detection — below 20 Hz for seismic activity, large-system resonance, infrasonic animal communication, and weather-adjacent environmental change.
360° plus spatial awareness — horizontal, vertical, overhead, around-corner, and behind-wall cues rendered as trainable haptic information.
Predictive environmental awareness — anomalies against the learned baseline of a place trigger distinct alerts.
Professional augmentation — engineers hearing stress frequencies in a bridge, clinicians extending auscultation beyond biological limits, musicians hearing harmonic detail beyond the unaided ear.
Sovereign Philosophy — Enforced at Every Layer
The Burgess Principle binary test applies to every OpenHear decision: does this feature treat the user as a sovereign individual with complete control over their own senses, or does it process them as a unit inside someone else's system. If the answer is the latter, it is redesigned until the answer is the former.
No proprietary algorithms at any layer.
No locked firmware.
No platform gatekeeping.
No company server receiving user data.
The user's audiogram, haptic preference profile, acoustic focus modes, therapeutic schedule, trained AI model, neural adaptation data, biometric correlations, and health outcomes belong exclusively and irrevocably to them.
The Acoustic Profile Store follows the same principles as the codebase: open, forkable, community-governed, and not controlled by a central authority.
The open-source licence is part of the technical architecture. No future owner gets to close the sovereignty path.
Burgess Principle extension point
The sovereign philosophy has an explicit API surface in advocacy/. It is a minimal, offline, dependency-free extension point that lets a companion advocacy tool (for example Iris, the reference Burgess Principle implementation) consume OpenHear records — audiograms, fitting profiles, MPO safety calculations — without OpenHear ever importing the companion or phoning home to it. The package produces SHA‑256 commitments over sovereign records, tags returning receipts as SOVEREIGN or NULL, and emits offline export bundles carrying both the OpenHear "experimental, not a medical device" disclaimer and an "advisory only, not legal advice" disclaimer. Raw environmental audio is refused at the adapter boundary by design. See docs/ADVOCACY_INTEGRATION.md for the full contract. A full advocacy workflow (tribunal-ready bundles, draft challenge language, shared vault formats) is scoped for post-v1.0.0 work with Iris.
For Industry Integrators
OpenHear's Sovereign Advocacy Layer is designed to be integrated into hearing device manufacturer software, audiology platforms, and AI clinical systems. If you have been granted permission by the author, start with docs/INTEGRATORS.md.
Advocacy quickstart
For a runnable, self-contained walkthrough of the full integration — happy path (SOVEREIGN bundle), tamper detection (NULL bundle), and the RawAudioRejectedError boundary — see examples/reference_integration.py. It imports only from advocacy and the Python standard library, and runs offline with no flags or configuration:
python examples/reference_integration.py
Accessibility profiles — fitting the body, not just the ears
Every other tuning path here starts from an audiogram. That is only half the fit. If your muscle tone shifts through the day, if vibration can trigger a spasm or a startle, if an involuntary movement can press a control you never meant to press, or if your speech varies widely between repetitions, the "correct" audiogram-derived settings can still be the wrong settings for you.
accessibility/ holds that second half as bounded, user-declared data. Cerebral palsy, autism, and sensory processing are equal opt-in starting points, not diagnoses. During a live wristband session, the selected profile dampens non-safety haptics, configures a firmware-enforced gradual onset, spaces alerts out, and rejects more low-confidence detections; cerebral palsy additionally supplies hold-to-confirm input defaults and dysarthria-tolerant voice scoring. Safety-critical alerts retain their perceptibility floor. Every value is overridable for the session, nothing is inferred or retained, and co-occurring conditions such as epilepsy are screened for, never assumed. See accessibility/README.md.
Contributing
If you wear hearing aids and you're frustrated — this is your repo too.
If you're a DSP engineer who wants to build something that actually matters to real people — open an issue.
If you're an audiologist who believes your patients should own their own data — we especially want to hear from you.
Before you open an issue or a pull request, please read:
CODE_OF_CONDUCT.md — Contributor Covenant 2.1, with
project-specific additions covering ableist language and the privacy of
audiometric data.
SECURITY.md — private vulnerability disclosure process,
including a dedicated path for hearing-safety reports. Do not file
hearing-safety issues in the public tracker.
CHANGELOG.md — running log of user-visible changes,
following Keep a Changelog. Add an
entry under [Unreleased] as part of any user-visible PR.
The repo is set up so that make ci reproduces what GitHub Actions runs.
make install-dev # editable install + ruff, pytest-cov, build, pre-commit
make lint # ruff check + ruff format --check
make format # ruff format + ruff check --fix
make test # pytest -q
make coverage # pytest with coverage (term + xml)
make build # python -m build → sdist + wheel into ./dist
make ci # lint + tests, same as the CI job
All tool configuration lives in pyproject.toml under
[tool.ruff], [tool.mypy], [tool.coverage], and a consolidated
[tool.pytest.ini_options] section (the old pytest.ini has been removed;
test discovery and behaviour are unchanged). Editor defaults are pinned in
.editorconfig, and .pre-commit-config.yaml
wires the same ruff checks into a pre-commit install hook so the
in-tree style stays consistent.
CI (.github/workflows/ci.yml) runs lint,
the test suite with coverage, a packaging smoke test (python -m build
followed by a pip install of the resulting wheel), and a Windows job to
match the README's "Windows 11 primary target" claim. A separate
CodeQL workflow provides static security
analysis of the Python codebase.
Phase 6 adds local listener preference capture, deterministic adaptive config
suggestions, and per-environment saved profiles. A May 2026 coverage pass
confirms the Python suite exercises the core DSP, audiogram, advocacy,
wristband, stream, hardware safety, and Phase 5 sovereign-device paths with
branch coverage enabled. The lowest-coverage gaps found in that pass were the
live wristband runtime loop and micro:bit firmware main-loop/fallback branches;
both now have deterministic tests using local hardware stubs, so mobile-native
work can start from a stronger regression baseline without requiring BLE, audio
devices, or a micro:bit in CI.
A note on repository hygiene: .gitignore no longer blanket-ignores
*.json, *.png, and *.pdf at every depth. Build and output
directories are ignored explicitly, so new fixtures, schemas, and
documentation media will not be silently dropped from commits.
Legal
OpenHear does not modify, reverse-engineer, or redistribute any proprietary firmware. It uses the Noahlink Wireless 2 and standard fitting software interfaces in the same way any hearing care professional would. It streams audio to hearing aids using standard Bluetooth audio profiles.
Your audiogram is yours. Your fitting data is yours. This software helps you access both.
Software: Apache 2.0. Firmware: MIT OR Apache-2.0. Hardware: CERN-OHL-S. Docs: CC-BY-SA.
Licensed under the Apache License, Version 2.0, with the OpenHear Sovereign Use
Addendum. See LICENSE and NOTICE for the full terms.
Safety & Disclaimer
⚠️ EXPERIMENTAL PROJECT — NOT A MEDICAL DEVICE
OpenHear is an experimental open-source project. It has not been evaluated, approved, or cleared by any regulatory body (FDA, MHRA, CE/UKCA, or equivalent). It is not a medical device. Consult a qualified audiologist before making any changes to your hearing aid configuration. Use at your own risk.
No comments yet. Be the first to ask about this board.