Internal reference design
Voice-capture badge reference design
A clip-on recorder for AI scribe, sales and field-service teams. It records clearly across a full shift, makes recording obvious to everyone nearby, and sends encrypted audio only to the client’s cloud.
Concept renderPhoto: badge sample on a lanyard and its PCBThe badge worn on a shirt, plus the bare board with both microphones visible
The challenge
AI scribe, sales-coaching and field-service companies want conversations captured without a phone in the middle of the table. Phones get muted, pocketed and switched to other apps. A dedicated badge solves that, but only if three things hold.
- The audio is good enough for transcription in a noisy clinic, store or job site, from a microphone pointed at the ceiling.
- The battery lasts a full shift with recording on for much of it.
- Nobody can say they did not know they were being recorded, and no recording passes through a server the client does not control.
We built this design so a client can start from working audio, power and security, and spend their budget on form factor and their own software.
Constraints
| Constraint | Target | Why |
|---|---|---|
| Runtime | [Hours of recording per charge — to fill] | One full shift without a mid-day charge. |
| Audio | Two microphones, 16 kHz or higher, beamforming or noise suppression on device | Speech-to-text accuracy drops fast with distance and noise. |
| Storage | [Hours of buffered audio — to fill], encrypted at rest | Records through dead zones and uploads later. |
| Consent | Push-to-record by default, a recording light that firmware cannot turn off while the mic is live | California and several other states require all-party consent to record a confidential conversation. Indicator and control choices reduce risk for the client’s users. |
| Data path | Device → client app or Wi-Fi → client cloud | No Duobay server and no China-hosted cloud in the path. |
| Wear | [Weight in grams, size — to fill], clip and magnet mount | If it is heavy or snags, it ends up in a drawer. |
Architecture
Part numbers below are example families we evaluate. Final parts are chosen per client at Gate 0.
| Block | Example part family | Notes |
|---|---|---|
| SoC | BLE SoC with DSP-capable Cortex-M core, e.g. Nordic nRF53-series class [to confirm]; Wi-Fi + BLE SoC for the Wi-Fi build [to confirm] | BLE relays through the client’s phone app. Wi-Fi uploads directly at a dock or on site. |
| Microphones | Two digital PDM MEMS microphones, high SNR [to confirm] | Spacing and port design set by the badge outline. Acoustic gasket tuned at EVT. |
| Audio processing | On-device noise suppression and two-mic beamforming [to confirm library and license] | Opus encoding to cut upload size. Raw PCM option for clients who want to run their own front end. |
| Storage | NOR flash or eMMC, sized to the buffer target [to confirm] | AES encryption at rest. Keys provisioned by the client. |
| Security | Secure element or SoC key storage [to confirm] | Device identity and keys the client controls. Signed firmware only. |
| Indicators and controls | Hardware-linked recording LED, one push-to-record button, haptic motor [to confirm] | The LED is wired so it lights whenever the microphones are powered. |
| Power | Li-ion or Li-polymer cell, charger with fuel gauge, USB-C or pogo-pin dock [to confirm] | UN38.3 test summary required to ship. |
Firmware and data handling
- Audio is encrypted on the device before it leaves. The client’s backend holds the keys to decrypt it.
- Upload goes to an endpoint the client sets: their API, or object storage in a US region they choose.
- Optional auto-delete on the device after a confirmed upload.
- Device-side protocol and SDK are delivered. The mobile app and cloud backend are the client’s, and we test against them.
- SBOM in SPDX or CycloneDX format at every release, including any audio-processing libraries and their licenses.
Compliance notes
- Recording consent. California Penal Code section 632 requires consent of all parties to a confidential communication. This design treats push-to-record and a visible light as defaults. Your counsel decides your policy.
- FCC. The BLE or Wi-Fi radio usually comes from a certified module. Body-worn use puts the antenna close to the user, so RF exposure conditions in the module grant need checking. See our FCC modular checklist.
- Health data. For AI scribe clients, HIPAA does not apply to the device by itself. The client’s healthcare customers will still ask for a BAA, encryption, access logs and retention controls. The design supports encryption, logs and retention settings on the device side.
Building a voice wearable? Start from working audio, power and encryption, and put Gate 1 into your form factor. Start from this design →
Gate timeline
Typical durations come from our standard gates. Status is filled in as the design moves.
| Gate | Typical duration | Scope in this design | Status |
|---|---|---|---|
| Gate 0 · Feasibility | 1–2 weeks | Use-case interviews, shift-length power budget, microphone and SoC shortlist, consent and indicator requirements, upload path (phone relay or Wi-Fi), FCC plan for the BLE / Wi-Fi radio. | [Done / in progress / not started — to fill] |
| Gate 1 · Works-like prototype | 3–6 weeks | Evaluation boards on a carrier with two PDM microphones. Firmware records, encodes and uploads to a test bucket. Audio quality and current measured. | [Done / in progress / not started — to fill] |
| Gate 2 · EVT · first custom PCB | 6–10 weeks | Custom board sized for a badge, acoustic port and gasket design, clip and magnet options, encrypted storage, OTA, EVT test report. | [Done / in progress / not started — to fill] |
| Gate 3 · DVT / PVT · small batch | 8–16 weeks | Wear tests over full shifts, drop and sweat tests, RF pre-scan, FCC certification in the client’s name, production audio test fixture. | [Done / in progress / not started — to fill] |
| Gate 4 · Mass production | Ongoing | Not applicable to a reference design. A client version enters Gate 4 under its own contract. | — |
Results
We publish measured numbers only. Until the bench data is ready, these stay blank.
| Measurement | Result | Conditions |
|---|---|---|
| Recording runtime | [Hours — to fill] | [Codec, upload mode, cell capacity — to fill] |
| Standby time | [Days — to fill] | [BLE advertising interval — to fill] |
| Transcription accuracy | [Word error rate — to fill] | [ASR engine, distance, noise level in dBA — to fill] |
| Buffered audio | [Hours — to fill] | [Storage size, bitrate — to fill] |
| Weight | [Grams — to fill] | [With clip, without lanyard — to fill] |
| RF pre-scan | [Pass / margin dB — to fill] | [Lab, standard — to fill] |
Related
Solution
Custom voice-capture wearables
Read →DataHow to build a voice wearable without audio passing through a China-hosted cloud
Read →Reference designLTE & GNSS tracker
Read →Next step
Tell us who wears the device, how long a shift runs and where the audio must end up. We will tell you what carries over from this design and what Gate 0 would cost. A Duobay engineer replies within 2 business days.