86 × 54 × 3.2 mm，30 克，20-24 小时录音；蓝牙协议开放，随货附参考代码
我们把蓝牙协议完整交付，并附一套安卓参考 App 源码（随样品订单提供）。你可以按自己的需求写转写、存储、检索那一层，把录音直接流进自己的知识库。我们只负责把声音真实记下来。
机身只有开始与停止。音频通过蓝牙回传，之后怎么转写、存在哪里、进哪个知识库，都由你的代码决定。
录音通过蓝牙 LE 从卡片传到手机，速度约 30 KB/s，一小时的录音大约 4 分钟传完。我们的安卓参考 App 在真机上跑通了每一步，你的团队从能跑的代码起步，而不是只拿到一份协议文档。
真机 2 分钟实录：连接、带实时速度的下载、断线续传、转文字、播放和删除。
同一段演示的手机竖屏版。
实测条件：安卓 9 手机，CB08 样机，固件 V1.0.0。换手机和固件，速度会有差别。
协议文档和安卓源码随样品订单提供。整机 ODM、贴牌和私有化部署另谈。
GATT 主服务 0xAE20，0xAE21 写、0xAE22 通知。指令集、文件传输与自检流程写在随样品订单提供的协议文档里。
上传、提交、取回、提问，四个接口就够了。也可以只要硬件和协议，把转写指向你自己的 ASR。
接收和转写这一层可以整套跑在你自己的机房，音频不出你的网络。会议、问诊、教学这类场景通常需要这个。
下面每一个数字都来自我们量产出货的机器实测，不是从芯片厂商的资料上抄的。凡是我们实测结果和厂商文档对不上的地方，都写明了，并给出我们实际测到的值。你的工程师拿到样机后，可以对着真机把每一行都验一遍。
一个主服务、一个写特征、两个通知特征。应答、音频和文件数据共用 0xAE22；按键与录音状态单独走 0xAE23，两路分开是为了避免半帧互相破坏。
| UUID | 属性 | 用途 |
|---|---|---|
| 0xAE20 | Primary Service | 业务服务 |
| 0xAE21 | WRITE_WITHOUT_RESPONSE | App → 设备 |
| 0xAE22 | NOTIFY | 应答、音频、文件列表、文件数据 |
| 0xAE23 | NOTIFY | 按键事件、录音状态 |
指令按 TYPE-CMD 成对。完整表格（含实时推流和分段下载）在随样品订单提供的协议文档里，下面这些是接入时最先会用到的。
| TYPE-CMD | 名称 | 参数 / 应答 |
|---|---|---|
| 0-0 | 同步时间 | year 2B LE + 月/日/时/分/秒 各 1B |
| 0-1 / 0-2 | 获取 / 应答 容量 | remain 4B LE + total 4B LE。单位是 1 KB，不是厂商文档写的 8 KB 块 |
| 0-3 / 0-4 | 获取 / 应答 电量 | 1B，0–100；110 表示充电中 |
| 0-10 / 0-11 | 获取 / 应答 固件版本 | 6B ASCII，如 V1.0.0 |
| 2-0 / 2-1 | 获取 / 应答 文件列表 | count 4B BE + N×28B 条目，可能跨多个通知 |
| 2-2 | 请求下载 | offset 4B LE + 文件名 24B —— 必须一次 36 字节 GATT 写完 |
| 2-3 / 2-4 / 2-5 | 开始 / 数据 / 结束 | 结束码 0=完成，1=不存在，2=offset 过大，3=其他 |
| 2-8 / 2-13 | 删除单个 / 应答 | 寻址方式与 2-2 相同，文件名要补回扩展名。应答 1B，0=成功 |
| 1-0 / 1-1 / 1-2 | 实时 开始 / 音频 / 结束 | 设备先回文件名，再推固定 40 字节的 OPUS 包 |
六件真花过时间才找到的事。写出来是因为，接入方要是毫无预警地撞上其中任何一条，第一反应都会是「这硬件坏了」。
设备内部就是以约 16 kbps 的 OPUS 存储的。请求 .wav 只是让设备把这份已经有损的音频解码成 256 kbps 的 PCM —— 音质一点不会变好，体积涨约 16 倍。安卓参考 App 实测约 30.7 KB/s：一小时录音（OPUS 约 7.2 MB）传到手机约 4 分钟。
实时流和从设备下载的文件，都是固定 40 字节的 OPUS 裸包，不带任何容器，存盘前必须自己封 Ogg。注意 Ogg 的 CRC-32 不反转、末尾不异或，跟 zlib 那个不是一回事。抄错了会生成一个「看着像 Ogg、每个播放器都拒收」的文件，而且没有任何报错提示你封错了。自检向量：oggCrc("123456789") == 0x89A1897F。
下载请求 2-2 是 36 字节，必须一次 GATT write 写完。安卓单次可写 = MTU−3，而默认 MTU 23 只能写 20 字节 —— 文件名被截断，设备回「文件不存在」。必须先 requestMtu(≥39) 成功再发，不够就直接报错；做「尽力而为」的降级只会得到一个莫名其妙的错误。
厂商文档说 0-2 返回的是 8 KB 块，实际返回的是 1 KB 为单位。当成 8 KB 会把容量算大 8 倍，当成字节会算小 1024 倍。两种都不会报错，只会显示一个离谱的数字。实测这台机是 28.8 / 29.1 GB 可用。
28 字节列表条目里那个 4 字节字段是时长，不是时间。唯一的时间来源是文件名本身 —— note20260830-014512 或 call20260830-014512。自己解析出来按它倒序排，并用前缀区分随手记和通话。
苹果禁止 iOS 上任何浏览器使用它，装了 Chrome 也不行，因为 iOS 上的 Chrome 内核仍是 WebKit。这是系统层面的限制，没有变通办法。iPhone 端必须走原生 CoreBluetooth。
骨传导麦克风常被误解，连上手用过这台设备的人也会搞错。它不是拾取佩戴者的颅骨振动。它是贴在手机背面拾取听筒振动 —— 因为通话不开免提时，空气麦根本收不到对方的声音。
由此带来的结果，是这台硬件上最有价值的一点。通话模式下，空气麦收到的基本就是本机说话人，振动麦收到的基本就是电话对方 —— 两个人在任何软件介入之前就已经被物理地分在两条轨上了。两条声道分别识别，再按每段的能量差归属，不用任何声纹模型就能做到接近准确的归属。单声道录音则退回引擎的 diarization_enabled，靠声音特征去猜，而且这个开关只对单声道生效。
八个端点。也可以只要硬件和协议，把转写指向你自己的 ASR，运行时一次都不调用我们。
| 端点 | 用途 |
|---|---|
| POST /rec/v1/upload | 上传音频文件 |
| POST /rec/v1/ingest | 提交转写 |
| GET /rec/v1/item/{id} | 转写稿、纪要、待办 |
| POST /rec/v1/ask | 就某段录音提问 |
| GET /rec/v1/list | 录音列表 |
| POST /rec/v1/item/{id}/speakers | 给说话人改名 —— 只重渲染，不重跑转写，不二次计费 |
| POST /rec/v1/retranscribe/{id} | 换一个 ASR 引擎重转 |
| POST /rec/t/{key}/search | 语音助手插件端点，永远返回 200，给出一句可直接朗读的话 |
接收和转写这一层整套跑在你的网络内，音频不出你的网络。要求不高 —— 这是一台无风扇小主机，不是 GPU 服务器。
| 项目 | 要求 |
|---|---|
| CPU | Intel N97 / N100 / N150。三者差距在 10% 以内，不值得纠结 |
| 内存 | 8 GB。实测峰值 797 MB —— 16 GB 是浪费 |
| 磁盘 | 模型 268 MB，加上客户资料 |
| 转写速度 | 约 4× 实时 —— 27 秒录音 6.5 秒出字 |
所有组件都核过可商用再分发。GeoNames 要求在页脚署名，其余的不需要。
| 组件 | 许可 |
|---|---|
| sherpa-onnx（ASR）、RapidOCR | Apache-2.0 |
| cndoc、anydoc、pdf-inspector、pdfplumber | MIT |
| pypdfium2 | BSD-3 |
| GeoNames 地名库 | CC BY 4.0 —— 页脚必须署名 |
不必。蓝牙协议文档和安卓参考 App 源码随样品订单交付。你可以把转写指向自己的 ASR、第三方服务，或者一台私有化部署的实例，运行时完全不调用我们的服务器。
可以。接收和转写这一层跑在你自己的服务器上，音频不经过我们。一台 Intel N97 或 N100、8 GB 内存的机器，转写速度约 4× 实时，会议、问诊、教学这类场景都够用。
通话模式下可以，而且不需要声纹模型 —— 空气麦和骨传导麦在物理上就把两个人分在了不同声道。单声道的环境录音则退回算法分离，可靠性要低一些。
通常 1,000 只。用现有模具加我们的包装，起订量可以再谈。现货机型最快 72 小时出样。
iOS 需要用 CoreBluetooth 做原生 App，因为苹果禁止 iOS 上所有浏览器使用 Web Bluetooth。协议是同一套，区别只在传输层的 API。App 可以我们做，也可以把协议交给你的团队。
可以先看视频。我们有一段 2 分钟的演示：安卓参考 App 在真机上连接录音卡、下载、续传、转文字。一小时录音传到手机约 4 分钟（实测 3 分 49 秒，30.7 KB/s）。安卓源码和蓝牙协议文档随样品订单提供。
上面每一个数字都是实测的，每一条说法都可以拿样机对着验证。完整的协议参考，包括实时推流、分段下载和全部实测踩坑表，写在随样品订单提供的协议文档里。
不必。蓝牙协议文档和安卓参考 App 源码随样品订单交付。你可以把转写指向自己的 ASR、第三方服务，或者一台私有化部署的实例，运行时完全不调用我们的服务器。
可以。接收和转写这一层跑在你自己的服务器上，音频不经过我们。一台 Intel N97 或 N100、8 GB 内存的机器，转写速度约 4× 实时，会议、问诊、教学这类场景都够用。
通话模式下可以，而且不需要声纹模型，空气麦和骨传导麦在物理上就把两个人分在了不同声道。单声道的环境录音则退回算法分离，可靠性要低一些。
通常 1,000 只。用现有模具加我们的包装，起订量可以再谈。现货机型最快 72 小时出样。
iOS 需要用 CoreBluetooth 做原生 App，因为苹果禁止 iOS 上所有浏览器使用 Web Bluetooth。协议是同一套，区别只在传输层的 API。App 可以我们做，也可以把协议交给你的团队。
可以先看视频。我们有一段 2 分钟的演示：安卓参考 App 在真机上连接录音卡、下载、续传、转文字。一小时录音传到手机约 4 分钟（实测 3 分 49 秒，30.7 KB/s）。安卓源码和蓝牙协议文档随样品订单提供。
一次连续录 25 小时，待机 15 天，400mAh 电池，磁吸 USB 充电。
2 个全向麦加 1 个骨传导麦克风，会议室、诊室、教室都能收干净。
86 × 54 × 3.2 毫米，就是一张银行卡的尺寸，约 28 克，铝合金一体机身，配皮套使用。0.42 英寸单色屏显示时间、电量与录音状态。
机身配色与丝印字符、皮套材质与压印 Logo、包装结构与全套印刷物、说明书与本地语言合规标签。软件侧可以做开机画面与屏幕 UI 字符、App 品牌化或直接用你自己的 App 接协议、按你指定接入转写与摘要引擎、专属知识库与私有化后台。
告诉我们使用场景、目标市场和预计量，我们出对应的报价与定制方案；样机可寄，蓝牙协议文档可先发一份给你的技术评估。
PINGOOD TECHNOLOGY CO. LIMITED (trading as AI HW Stack）是深圳的 AI 硬件 ODM/OEM。我们一站式交付完整方案：工业设计与模具、主板、Android 固件、ASR + LLM + TTS 语音链路、配套 App 和云端后台，一个订单全部完成。
我们使用的技术： Android TV, Azure AI Speech, OpenAI speech-to-text, Alibaba Model Studio, Cloudflare Workers.
发布于 2026-09-01 · · Contact: kristy@aihwstack.com
