Sample price, not a volume price.
Request a sample86 × 54 × 3.2 mm, 30 g, 20-24 h recording. Open Bluetooth protocol, reference code included.
We hand over the full Bluetooth protocol along with a set of reference code. You write the transcription, storage and retrieval layer the way your business needs it, and stream recordings straight into your own knowledge base. Our job is to capture the sound faithfully.
The device has start and stop, nothing else. Audio comes back over Bluetooth; how it is transcribed, where it is stored and which knowledge base it enters is decided by your code.
Recordings move from the card to the phone over Bluetooth LE at about 30 KB/s, so a one-hour recording arrives in about 4 minutes. Our Android reference app shows every step working on real hardware, so your team starts from working code instead of a protocol document.
2 minutes on a real phone: connect, download with live speed, resume after a drop, speech-to-text, playback and delete.
The same demo in phone format.
Measured on an Android 9 phone with a CB08 sample, firmware V1.0.0. Speed on your phone and firmware will vary.
Full Android source code (plain Java, no third-party libraries) and the BLE protocol document are provided with sample orders.
Protocol document and Android source come with the sample order. ODM, white-label and on-premise deployment are quoted separately.
GATT main service 0xAE20, write on 0xAE21, notify on 0xAE22. Command set, file transfer and self-check are in the protocol document that ships with the sample order.
Upload, ingest, fetch, ask: four endpoints and you are done. Or take the hardware and protocol only, and point transcription at your own ASR.
The receiving and transcription layer can run entirely inside your own server room, so audio never leaves your network. Meetings, consultations and teaching usually need this.
Everything below is measured on units we have shipped, not copied from a vendor datasheet. Where our measurements disagree with the chip vendor’s documentation, we say so and give the number we actually observed. Your engineers can check every line of it against a real device once the sample is in hand.
One primary service, one write characteristic, two notify characteristics. Replies, audio and file data share 0xAE22; key and recording-state events are isolated on 0xAE23 so the two streams cannot corrupt each other’s partial frames.
| UUID | Property | Use |
|---|---|---|
| 0xAE20 | Primary Service | Main service |
| 0xAE21 | WRITE_WITHOUT_RESPONSE | App → device |
| 0xAE22 | NOTIFY | Replies, audio, file list, file data |
| 0xAE23 | NOTIFY | Key events, recording state |
Commands are TYPE-CMD pairs. The full table, including realtime streaming and segmented download, is in the protocol document that ships with the sample order; these are the ones an integration needs first.
| TYPE-CMD | Name | Params / reply |
|---|---|---|
| 0-0 | Sync time | year 2B LE + month/day/hour/min/sec, 1B each |
| 0-1 / 0-2 | Get / reply storage | remain 4B LE + total 4B LE. Unit is 1 KB, not the 8 KB blocks the vendor doc states |
| 0-3 / 0-4 | Get / reply battery | 1B, 0–100; 110 means charging |
| 0-10 / 0-11 | Get / reply firmware | 6B ASCII, e.g. V1.0.0 |
| 2-0 / 2-1 | Get / reply file list | count 4B BE + N×28B entries; may span several notifications |
| 2-2 | Request download | offset 4B LE + filename 24B — must be one 36-byte GATT write |
| 2-3 / 2-4 / 2-5 | Begin / data / end | end code 0=ok, 1=not found, 2=offset too large, 3=other |
| 2-8 / 2-13 | Delete one / ack | same addressing as 2-2, extension restored. Ack 1B, 0=ok |
| 1-0 / 1-1 / 1-2 | Realtime start / audio / stop | device sends the filename, then fixed 40-byte OPUS packets |
Six things that cost us real time to find. We publish them because an integrator who hits them without warning will assume the hardware is broken.
The device stores roughly 16 kbps OPUS internally. Requesting a .wav only makes it decode that already-lossy audio to 256 kbps PCM — no quality gain, about 16× the bytes. On the Android reference app a one-hour recording (about 7.2 MB as OPUS) reaches the phone in about 4 minutes, measured at 30.7 KB/s.
Both the realtime stream and the files pulled off the device are fixed 40-byte OPUS packets with no container. You have to wrap them in Ogg before saving. Ogg’s CRC-32 is non-reflected with no final XOR — it is not zlib’s. Get it wrong and you produce a file that looks like Ogg and every player silently refuses. Test vector: oggCrc("123456789") == 0x89A1897F.
The 2-2 download request is 36 bytes and must go out as a single GATT write. On Android one write is MTU−3, and the default MTU of 23 allows only 20 bytes — the filename gets truncated and the device answers “file not found”. Require requestMtu(≥39) to succeed and fail loudly; a best-effort fallback just produces a confusing error.
The vendor documentation says 0-2 returns 8 KB blocks. It returns 1 KB units. Treating them as 8 KB inflates capacity eightfold; treating them as bytes shrinks it by 1024. Neither raises an error — you simply display an absurd number. A verified unit reports 28.8 of 29.1 GB usable.
The 4-byte field in each 28-byte list entry is duration, not time. The only source of time is the filename itself — note20260830-014512 or call20260830-014512. Parse it, sort newest first, and use the prefix to tell ambient recordings from calls.
Apple blocks it in every iOS browser, Chrome included, because Chrome on iOS is WebKit underneath. This is an operating-system restriction with no workaround. An iPhone app has to use native CoreBluetooth.
The bone-conduction microphone is commonly misread, including by people who have handled the device. It does not pick up the wearer’s skull. It sits against the back of the phone and picks up earpiece vibration, because an air microphone cannot hear the far end of a call that is not on speaker.
The consequence is the most useful thing about this hardware. In call mode the air microphone is effectively the near speaker and the vibration microphone is the remote party — the two voices are separated physically, before any software runs. Transcribe each channel and assign segments by energy difference and you get near-perfect attribution with no voiceprint model at all. Mono recordings fall back to the engine’s diarization_enabled, which only applies to mono and guesses from voice characteristics.
Eight endpoints. Or take the hardware and the protocol only, point transcription at your own ASR, and never call us at runtime.
| Endpoint | Purpose |
|---|---|
| POST /rec/v1/upload | Upload an audio file |
| POST /rec/v1/ingest | Submit for transcription |
| GET /rec/v1/item/{id} | Transcript, summary, action items |
| POST /rec/v1/ask | Ask a question about a recording |
| GET /rec/v1/list | List recordings |
| POST /rec/v1/item/{id}/speakers | Rename speakers — re-renders only, no re-transcription, no extra charge |
| POST /rec/v1/retranscribe/{id} | Re-run with a different ASR engine |
| POST /rec/t/{key}/search | Voice-assistant plugin endpoint; always returns HTTP 200 with one speakable sentence |
The receiving and transcription layer runs entirely inside your network, with no audio leaving it. It is not demanding — this is a small fanless box, not a GPU server.
| Item | Requirement |
|---|---|
| CPU | Intel N97 / N100 / N150. Within 10% of each other; not worth agonising over |
| RAM | 8 GB. Measured peak 797 MB — 16 GB is wasted |
| Disk | 268 MB of models, plus customer data |
| Throughput | About 4× realtime — 27 seconds of audio transcribed in 6.5 seconds |
All components are cleared for commercial redistribution. GeoNames requires attribution in your footer; the rest do not.
| Component | Licence |
|---|---|
| sherpa-onnx (ASR), RapidOCR | Apache-2.0 |
| cndoc, anydoc, pdf-inspector, pdfplumber | MIT |
| pypdfium2 | BSD-3 |
| GeoNames place database | CC BY 4.0 — attribution required in the footer |
No. The Bluetooth protocol document and the Android reference app source code ship with the sample order. You can point transcription at your own ASR, at a third-party service, or at an on-premise instance, and never call our servers at runtime.
Yes. The receiving and transcription layer runs on your own server, and no audio passes through us. An Intel N97 or N100 box with 8 GB of RAM transcribes at roughly 4× realtime, which is enough for meetings, consultations and teaching.
In call mode, yes, and without a voiceprint model — the air microphone and the bone-conduction microphone physically capture the two parties on separate channels. Mono ambient recordings fall back to algorithmic diarization, which is less reliable.
1,000 pieces is typical. Lower is negotiable on the existing tooling with our packaging. The fastest sample turnaround on a stock unit is 72 hours.
iOS needs a native app using CoreBluetooth, because Apple blocks Web Bluetooth in every browser on iOS. The protocol is the same; only the transport API differs. We can build the app or hand the protocol to your team.
Yes, as a video. We have a 2-minute demo of our Android reference app running on a real phone with the recorder. A one-hour recording reaches the phone in about 4 minutes (measured 3 min 49 s at 30.7 KB/s). The Android source code and the BLE protocol document come with the sample order.
Every number above is measured, and every claim can be verified against a real unit. The full protocol reference, including realtime streaming, segmented download and the complete field-notes table, is in the protocol document that ships with the sample order.
No. The Bluetooth protocol document and the Android reference app source code ship with the sample order. You can point transcription at your own ASR, at a third-party service, or at an on-premise instance, and never call our servers at runtime.
Yes. The receiving and transcription layer runs on your own server, and no audio passes through us. An Intel N97 or N100 box with 8 GB of RAM transcribes at roughly 4× realtime, which is enough for meetings, consultations and teaching.
In call mode, yes, and without a voiceprint model, the air microphone and the bone-conduction microphone physically capture the two parties on separate channels. Mono ambient recordings fall back to algorithmic diarization, which is less reliable.
1,000 pieces is typical. Lower is negotiable on the existing tooling with our packaging. The fastest sample turnaround on a stock unit is 72 hours.
iOS needs a native app using CoreBluetooth, because Apple blocks Web Bluetooth in every browser on iOS. The protocol is the same; only the transport API differs. We can build the app or hand the protocol to your team.
Yes, as a video. We have a 2-minute demo of our Android reference app running on a real phone with the recorder. A one-hour recording reaches the phone in about 4 minutes (measured 3 min 49 s at 30.7 KB/s). The Android source code and the BLE protocol document come with the sample order.
25 hours of continuous recording and 15 days on standby, from a 400mAh cell charged over a magnetic USB connector.
Two omnidirectional microphones plus one bone-conduction microphone, which stays clean in a meeting room, a consulting room or a classroom.
86 × 54 × 3.2 mm, the footprint of a bank card, at about 28 grams in a one-piece aluminium body used with a leather sleeve. A 0.42-inch monochrome screen shows time, battery and recording state.
Housing colour and silkscreen characters, sleeve material and embossed logo, packaging structure and the full print set, manual and local-language compliance labels. On the software side, the boot screen and on-screen UI text, a branded app or your own app speaking the protocol, the transcription and summarisation engines you nominate, and a private knowledge base and on-premise backend.
Tell us the use case, target market and expected volume, and we will come back with pricing and a customisation plan. Samples can ship; the Bluetooth protocol documentation can go to your engineers ahead of that.
PINGOOD TECHNOLOGY CO. LIMITED (trading as AI HW Stack) is a Shenzhen-based AI hardware ODM/OEM. We deliver the complete stack — industrial design and tooling, mainboard, Android firmware, the ASR + LLM + TTS pipeline, the companion app and the cloud backend — as one order.
Technology we build on: Android TV, Azure AI Speech, OpenAI speech-to-text, Alibaba Model Studio, Cloudflare Workers.
Published 2026-09-01 · · Contact: kristy@aihwstack.com
