Concept renderPendant
Recording pendant
Worn on a cord or magnet through meetings and site visits. Two mics, a record button and a light the other person can see.
Products · AI recording wearables
Your users will not wear a recorder that is bulky, dies mid-day or records without asking.
We design and build recording rings, pendants, clip-on recorders and recording cards for AI scribe, sales and meeting software companies. Small enough to forget, a battery that lasts the day, consent built into the hardware, and audio that goes only to your cloud.
Concept renderForm factors
What an AI recorder can look like
Your software already works on a phone. A dedicated device gets better audio, fewer missed recordings and a product you can sell on its own.
Concept render
Concept renderRing
Recording ring
Tap to capture a voice note or a short exchange. The hard parts are mic placement under a finger and a battery the size of a grain of rice.
Concept renderClip-on
Clip-on recorder
Lavalier-style transmitter for interviews, sales calls and clinic visits. Records locally as a backup when the wireless link drops.
Pin
Badge or pin for frontline staff
Lanyard or pin back, gloves-on button, shift-length battery, survives disinfectant wipes.
Recording card
Card recorder with LTE
Wallet-sized recorder with its own SIM for phone-call capture and direct upload. Heavier certification path; see trackers.
Desk
Meeting puck
Mic-array tabletop unit for in-room meetings, feeding the same transcription and summary pipeline.
System
From the microphone to your summary
A recording device is five systems that must agree on states, files and failures. We build the first four and test against the fifth.
- 01
Capture
Two or more MEMS mics, beamforming, wind and fabric-noise suppression in the real enclosure.
- 02
Device
Encode (Opus, LC3 or PCM), encrypt, buffer to flash, survive full storage and power loss.
- 03
Sync
BLE transfer to the phone with resume on reconnect, or Wi-Fi / LTE-M direct upload. Signed OTA.
- 04
App & backend
Optional. Recording list, sync status, device settings; upload API and storage in your cloud account.
- 05 · YOURS
Your AI
Your speech-to-text, summaries, action items and search. We test against your endpoint.
Engineering record
A wireless recorder that never loses the take
Clip-on transmitters that stream to a receiver and record to their own flash at the same time. If the wireless link drops, the local copy keeps the audio. Built by our Shenzhen team; client name withheld.
- Audio
- 48 kHz / 24-bit WAV, uncompressed
- Onboard storage
- 8 GB, up to 14 h, 30-min segments
- Link
- One receiver, two transmitters
- Range
- Up to 250 m, line of sight
- Runtime
- 7.5 h per transmitter, case recharge
- Mass
- 33 g transmitter
- Processing
- Noise reduction, low-cut filter, safety track
- Modes
- Mono, stereo or safety track
Figures are from the product's specification sheet. Range depends on environment.
PCB layout
PCB layoutReference architecture
Inside a typical recording wearable
Most recording wearables share the same five blocks. The choices inside each block decide runtime, size and certification cost.
| Block | For example | Why it matters |
|---|---|---|
| SoC | Nordic nRF5340 or nRF54L series; Espressif ESP32-S3 when Wi-Fi offload is needed; Ambiq Apollo for the longest runtime | Opus or LC3 encoding on device, hardware AES, secure boot |
| Microphones | Knowles SiSonic or TDK InvenSense digital MEMS (for example the T5838 with acoustic activity detection) | Two mics for beamforming and wind or rustle rejection |
| Radio | Bluetooth LE 5.x on the SoC; optional Wi-Fi for direct upload; LTE-M only if the device must upload without a phone | Usually a pre-certified module or a certified SoC reference layout |
| Storage | SPI NOR or NAND flash, sized for one to several shifts of encoded audio | Opus at 24 kbps is about 11 MB per hour, so an 8-hour shift fits in about 90 MB |
| Power | 150–400 mAh Li-Po, a PMIC such as Nordic nPM1300 or a TI charger, fuel gauge | USB-C or pogo-pin dock; shift-length runtime is the usual target |
| App & cloud | Your backend, or an app and backend we build in your cloud account | By default we deliver the device protocol and SDK and test against your endpoint; app and backend are an option |
Part names are examples only. Final selection happens at Gate 0 against your runtime, size, cost and module-origin requirements.
Key technologies
The engineering that decides whether people keep wearing it
A recording device fails in the field for small reasons. Clothing rustle ruins the audio. The battery dies at 3 p.m. People forget it is on. We work on these from the first prototype.
- Audio front end. Two-mic beamforming, wind and fabric-noise suppression, automatic gain, and a mic port and gasket design tested in the actual enclosure.
- Codec choice. Opus, LC3 or raw PCM, matched to what your speech model expects. We measure the effect on your model's word error rate as well as file size.
- Low-power design. Acoustic activity detection on the mic, SoC sleep states, and a measured current profile per mode.
- Consent hardware. A physical record button, and an LED powered from the same rail as the microphones, so firmware cannot record with the light off.
- Secure storage and transfer. AES encryption at rest, per-device keys provisioned on the line, BLE pairing with LE Secure Connections, signed OTA updates.
- Wearability. Ring sizing, magnetic clip, lanyard or pin back; mass under 30 g is a common target for clip-ons; housings that tolerate sweat and clinical wipes.
- Sync that survives real life. Interrupted transfers resume, full storage has a defined behavior, and the app always knows which recordings are safe to delete.
Certification path
What a recording wearable must pass before you sell it in the US
A Bluetooth-only recorder has one of the lighter paths of any category. Adding Wi-Fi or LTE changes the table. We map yours at Gate 0 and file in your company's name.
| Requirement | When it applies | How we handle it |
|---|---|---|
| FCC Part 15 Subpart C (§15.247) | Bluetooth LE or 2.4 GHz Wi-Fi transmitter | Use a pre-certified module where the form factor allows. A chip-down design needs its own intentional-radiator testing. |
| FCC Part 15 Subpart B | Every device with digital circuitry | Unintentional emissions. Still required when the radio module is pre-certified. |
| RF exposure (47 CFR §1.1307, §2.1093) | Worn within 20 cm of the body | Low-power BLE often qualifies for an exemption. Wi-Fi or LTE in a body-worn device usually needs SAR testing. The lab confirms which applies. |
| UN38.3 + 49 CFR §173.185 | Any lithium cell shipped with or in the device | Shippers and Amazon ask for the test summary. Plan it with the cell supplier at Gate 2. |
| IEC 62133-2 | Rechargeable cell and pack safety | Not a federal requirement, but many retailers and enterprise buyers ask for it. |
| HIPAA (BAA, not a certification) | Devices used with patient audio | The device is not certified for HIPAA. Your health-system customers will review encryption, access logs and retention. We document all three. |
Rules as of October 2026. Primary sources: 47 CFR Part 15, 47 CFR §2.1093, 49 CFR §173.185. Lab and certification fees are paid by you; we manage the process. How we plan FCC work.
Small batches
How a 10–1,000 units run works for a recording device
Recording products are often piloted with one customer site before a wider launch. The gates are built for that.
- Gate 1, works-like (3–5 units, 3–6 weeks). Dev-kit SoC and mic boards on a custom carrier. Your team records real conversations and runs them through your model.
- Gate 2, EVT (10–30 units, 6–10 weeks). First custom PCB and enclosure. We measure runtime, audio quality in the housing and drop behavior.
- Gate 3, pilot (10–1,000 units, 8–16 weeks). A pilot with one clinic group or sales region. Certification runs in parallel.
Every unit off the line goes through a production test we write with you:
- Mic sensitivity and frequency response in a small acoustic test box, against limits set from EVT data
- BLE conducted power check and pairing test
- Unique key injection, with serial and public key logged to a file you keep
- Charge, LED and button check; battery capacity sampled per lot
Data sovereignty
Audio goes to your cloud and nowhere else
Recorded conversations are the most sensitive data your customers have. The device is designed so that only you can read them.
- No Duobay server and no China-hosted service in the data path. Devices talk to your backend or to a US cloud region you choose.
- You generate and hold the signing keys and device credentials. We can run key injection with keys your team provides.
- Audio is encrypted on the device and deleted after a confirmed upload, with retention set by your firmware config.
- You receive the firmware source and a software bill of materials (SBOM) listing every library, version and license.
- We document the security design for your customers' vendor reviews and HIPAA business associate assessments.
Start from proven work
Reference design and reading
Concept renderVoice-capture badge
Two microphones, push-to-record, a visible recording light and encrypted upload to your cloud. The mic, codec and power work is done.
View design →Further reading
Keeping a voice wearable's data out of China-hosted clouds
What to check in a supplier's firmware, SDK and update servers before your first pilot.
AI recording wearables: common questions
Why push-to-record by default instead of always-on?
California is an all-party consent state for recording confidential conversations (Penal Code §632), and lawsuits over AI listening devices are active as of October 2026. A physical button and a visible recording light make consent easy to ask for and easy to prove. You can change the default, and we will document the trade-off.
Can the audio skip the phone and go straight to our cloud?
Yes, with Wi-Fi or LTE-M on the device. Both add cost, battery and certification work. Most scribe and sales devices use the phone as the uplink and keep the badge on Bluetooth LE only.
How long does a badge run on one charge?
It depends on duty cycle, codec and battery size. A typical target is a full shift of intermittent recording plus standby. We measure real current draw on the Gate 1 prototype and give you the numbers before you commit to an enclosure size.
Will it work with our existing AI scribe or transcription stack?
Yes. You choose the codec and sample rate your speech model expects, and we deliver a device SDK and a test harness that uploads to your endpoint. We do not run transcription or host audio on our own servers.
Can you build the companion app and backend?
Yes, as an option. We build the iOS and Android app for pairing, sync and settings, and an upload and storage backend, deployed in your own cloud account. Transcription and summaries stay with your models or the provider you choose. App, cloud and AI.
Do we need FDA clearance for a clinical recorder?
Usually not, if the device only records and does not diagnose or guide treatment. Your regulatory counsel should confirm based on your intended-use claims. We can keep the hardware design compatible with a later medical filing if you plan one.
Can we start from an existing design?
Often, yes. Our team has shipped wireless recorder and mic-array boards, and the voice-capture badge reference design has the mic, codec and power work done. Starting from proven boards can shorten Gate 1 and Gate 2.
Next step. Tell us about your users, your speech stack and your target pilot size. A Duobay engineer replies within 2 business days.