6 篇文章 含有標籤「技術深度」

錄音裝置要把一段 MP3 傳到雲端，表面上像是「把檔案送出去」；真正困難的地方卻在於：模組的 AT 介面有長度上限，UART 可能比 LTE 快或慢，網路會在任何一片中間斷線，而裝置又不能因為收到一個看似成功的狀態碼就刪掉唯一的本地副本。

這篇整理一套可移植到 MCU 錄音卡的工程模型：使用 SCS527E 建立 TLS socket，由 MCU 自行組裝 HTTP/1.1 請求，以原始 MP3 bytes 分片傳送，再用帶有檔案身份、分片 SHA-256 與冪等鍵的 JSON 回執推進 checkpoint。重點不是某一個產品，而是如何把「可連線」做成「可恢復、可驗證、可量產」。

HTTP/1.1 → TLS → TCP → LTE Cat.1

1. 為什麼選 HTTP over TLS Socket​

高階 HTTP AT 命令看起來最省事，但在「每片都有身份、摘要與回執」的錄音上傳中，控制權很重要。

AT+HTTPPOST 可以作為供應商功能測試、相容性實驗或檔案系統 staging 的工具；它不應被直接當成「某一片錄音已被正確接收、可以刪除本地檔」的唯一證據。對於可恢復的分片上傳，direct TLS socket 讓裝置能精確知道：本次送出的 body 有多長、它屬於哪一個 upload、伺服器回覆的是哪一片。

2. SCS527E 的原廠邊界​

設計必須先服從模組文件，而不是從一次成功的 PC 測試倒推出理論能力。以下數值以 SCS527E 原廠文件為準；對應資料位置列在文末。

這裡有三個很容易混淆的單位：

1. 應用層 chunk：例如一片 3072 B 的 MP3 body，對應一個 checkpoint 和一個應用回執。
2. HTTP request：包含 header 與該片 raw body。
3. SSLSEND data phase：每次最多 1460 B，可能只包含 header、只包含 body，或跨過 header/body 邊界。

因此，3072 B body 通常要拆成多個 SSLSEND，但它仍然只是一個應用片；不能看到 AT 寫入次數就誤判檔案被分成了那麼多片。

3. 從 Mic 到伺服器的完整資料平面​

┌──────────┐   ┌──────────────┐   ┌─────────┐   ┌────────────┐
│ Mic/ADC  │ → │ MP3 + NAND  │ → │ SHA-256 │ → │ checkpoint │
└──────────┘   └──────────────┘   └────┬────┘   └─────┬──────┘
                                      │               │
                                      ▼               ▼
                              ┌─────────────────────────┐
                              │ UART：HTTP header + raw  │
                              │ MP3 body，分段 SSLSEND   │
                              └────────────┬────────────┘
                                           ▼
                                      ┌─────────┐
                                      │ SCS527E │
                                      └────┬────┘
                                           │ TLS/TCP/LTE
                                           ▼
                              ┌─────────────────────────┐
                              │ HTTPS ingest             │
                              │ bytes/SHA/idempotency   │
                              └────────────┬────────────┘
                                           ▼
                              identity-bound JSON receipt

一個穩定的 upload 至少要有以下身份欄位：

• upload_id：整個檔案的穩定身份，不因重試改變；
• chunk_index / total_chunks：分片位置與總數；
• Content-Length：本片 原始 MP3 body 的 byte 數，不包括 HTTP header；
• chunk_sha256：本片內容摘要；
• file_sha256：整個錄音檔的摘要；
• Idempotency-Key：通常可由 upload_id:chunk_index:chunk_sha256 組成，讓伺服器能安全處理重送。

MCU 組出的請求可以抽象成這樣。路徑只是示意，正式端點應由產品後端定義：

POST /ingest/v1/audio/chunks HTTP/1.1
Host: upload.example.invalid
Content-Type: audio/mpeg
Content-Length: 3072
X-Upload-Id: <stable-upload-id>
X-Chunk-Index: 3
X-Total-Chunks: 7
X-Chunk-SHA256: <chunk-sha256>
X-File-SHA256: <whole-file-sha256>
Idempotency-Key: <upload-id>:3:<chunk-sha256>
Connection: keep-alive

[3072 bytes of the original MP3 body]

header 之後的 body 是二進位原文，不是 Base64、HEX，也不是以 \0 結尾的 C 字串。0x00、0x1A、CR、LF 都必須依照明確長度傳輸。

4. 一片資料的交易狀態機​

每片應該是一個可以重放、可以驗證、可以中斷後恢復的交易：

穩定 MP3
   │
   ├─ 計算 file_sha256 / upload_id
   ├─ 讀取 chunk body，計算 chunk_sha256
   ├─ 組 HTTP header
   ├─ header + raw body → 多次 SSLSEND（每次 ≤ 1460 B）
   ├─ 依 SSLURC length 收滿 HTTP response
   ├─ 驗證 status + JSON + upload_id + index + bytes + SHA
   │
   ├─ 通過：寫入 checkpoint，進入下一片
   └─ 失敗：保留原片，有限退避後用同一個 key 重試

為什麼不把 201 或 socket closed 當作刪除條件​

HTTP 201 只表示伺服器接受了某個請求；如果回執被截斷、upload_id 錯配、body 長度錯誤，裝置仍不能證明「本地這一份檔案」已被正確保存。socket closed 甚至只說明連線結束，可能發生在伺服器回覆之前。

更安全的刪除策略是另外取得一個帶身份的完成回執，至少同時滿足 complete=true、verified=true、delete_allowed=true，並比對本地整檔 bytes 與 SHA。若 status 端點尚未經過正式部署與實機驗收，刪除開關就應保持關閉。

5. 為什麼不用 Base64、MQTT 大 payload 或裸 TCP​

Base64​

Base64 會把資料量增加約三分之一，並且需要額外的編碼 buffer、CPU 時間與長度換算。對已經是二進位 MP3 的 body，直接以 Content-Length 傳 raw bytes 更簡單，也更容易用 SHA-256 驗證「傳了什麼」。

MQTT 大 payload​

MQTT 很適合事件、遙測與小訊息，但把一個錄音檔塞成大 payload 後，重試邊界、broker 限制、QoS 語意、分片身份和檔案完成狀態仍然要自己補上。若最後仍要自訂 chunk、hash、冪等和組裝服務，MQTT 並沒有自動提供錄音檔的可靠提交語意。

裸 TCP​

裸 TCP 沒有伺服器身份驗證，也沒有 HTTP 的狀態、header 與代理/觀測工具生態。除非產品另行設計完整的 TLS、身份認證、版本、錯誤與重放防護，否則不能用「TCP 連得上」代替 HTTPS 的安全邊界。

6. 長連線 keep-alive：減少握手，不減少驗證​

長連線的作用是讓多片資料在同一個 TLS socket 上依序傳送，避免每一片都重新做 TCP/TLS 建連。它不是把回執省掉，也不是允許 MCU 盲目連續塞入多片。

安全規則很簡單：

1. 只有伺服器實際回覆 Connection: keep-alive，才把 socket 標成可復用。
2. 每片仍然要等完整 HTTP response 和 JSON receipt。
3. 任何 Connection: close、closed、逾時、解析失敗或回執身份錯誤，都回退到「一片一連線」或重新 SSLOPEN。
4. 重連後沿用相同 upload_id、chunk index、body 和冪等鍵，讓後端可以判斷重送是否已經存在。

因此，keep-alive 是可靠性不變前提下的提速選項，而不是跳過提交確認的捷徑。

7. 一次實測告訴了我們什麼​

以下數字是單次伺服器觀測，不是理論上限，也不是量產效能承諾：

這個計時包含每片等待回執的時間，但不一定包含第一次 PDP、DNS、TLS SSLOPEN 的全部前置成本；它也不是 LTE 基地台的物理層吞吐率。

以 32 kbps CBR MP3 粗估：

• 一小時錄音約 32,000 / 8 × 3,600 = 14,400,000 B，即約 14.4 MB（13.73 MiB）；
• 以 27.7 kbps 的有效上傳速度，單純除法約需 69.3 分鐘，還未加首次連線、重試與網路波動；
• 因為音訊產生速率 32 kbps 高於這次觀測到的 27.7 kbps，無限邊錄邊傳會形成積壓，約每小時增加 1.9 MB。

所以目前更合理的產品模式是「停止錄音、完整刷盤、背景上傳」。若要改成真正的邊錄邊傳，平均有效速度必須長期高於編碼速率，還要重新設計檔案一致性、掉電恢復與本地緩衝，不是把上傳執行緒移到錄音執行緒旁邊就完成。

8. 提速路線：先保可靠，再提高吞吐​

提速順序應該按照「改動小、可回退、容易證明」排列：

不要把 921600 或 3 Mbps 寫成「已可用」：硬體手冊提到的 MAIN UART 能力，和目前 AT 文件的固定 AT+IPR 列表不是同一層證據。現階段可以審計的最高目標是 460800，而且仍需要真模組和真板 HIL。

高速切換的安全步驟​

AT+IPR 是保存型設定，且原廠說明不支援自動波特率自適應。正確流程是：

1. 以已知的 115200 啟動，記錄 AT+IPR=? 和韌體版本回應。
2. 先測 230400，再測 460800；每次都同步切換 MCU UART 和模組設定。
3. 以 AT / AT+IPR? 雙向確認，保留外部救援或 PWRKEY/RESET 回退路徑。
4. 每個檔位用同一批音訊測成功、斷線、重置、重試與摘要一致性。
5. 只有連續 HIL 通過，才把新速率放進獨立候選 profile；原 115200 profile 必須保留。

9. 證據邊界：哪些已知，哪些仍未完成​

工程文件最容易犯的錯，是把「原始碼存在」「PC 序列埠成功」和「整機量產完成」寫成同一件事。應該分層記錄：

這個表不是保守措辭，而是讓測試、硬體、後端和產品驗收各自有明確的完成條件。

10. 量產安全與隱私紅線​

1. 錄音不能走裸 TCP/UDP，也不能因 MQTT 「有 QoS」就跳過檔案級摘要與完成語意。
2. 生產 TLS 必須校驗 CA、可信時間、SNI 和伺服器身份；錯誤 CA、錯誤時間與錯誤 hostname 都應該失敗。
3. upload_id 是冪等身份，不是認證憑據。正式後端仍需要每設備認證、防重放、權限、儲存加密、保留與刪除政策、審計記錄。
4. 日誌只能輸出檔案大小、分片序號、狀態碼與摘要結果；不要輸出 token、私鑰、activation code、內網 IP、完整測試端點或音訊正文。
5. seclevel=0 僅可留在隔離的臨時互通測試，不能和生產設定共用，也不能在公開文件中提供可直接利用的憑證繞過設定。
6. 自動刪除是獨立的產品決策：在後端完整回執、裝置身份、掉電恢復和資料保留政策都未驗收前，預設保留本地錄音。

11. 一份可以直接拿去做 HIL 的清單​

[ ] 以真實 SCS527E 執行 AT+IPR=?、AT+IFC=? 與 AT+SSLCFG=?
[ ] 確認 1.8 V 電平、共地、供電峰值、PWRKEY/RESET 與 SIM/PDP
[ ] 上傳多片真實 MP3，確認每片 receipt、整檔 SHA 與檔案大小
[ ] 測 keep-alive 真復用；伺服器回 close 時驗證安全回退
[ ] 測斷網、TLS close、模組 reset、MCU reset、掉電與 checkpoint resume
[ ] 在 115200、230400、460800 分別做同批音訊的重複測試
[ ] 只有先擴大 MCU Kconfig/buffer/重傳邊界後，才做 3072 → 4096 A/B
[ ] 接上 RTS/CTS 後做高 baud 溢位、長時間傳輸與錯誤注入
[ ] 驗證生產 CA、時間、SNI、seclevel=1、裝置認證與撤銷策略
[ ] 在 status receipt 通過前，保持本地檔案不可自動刪除

12. 原廠資料定位​

本文的模組參數與 AT 行為以以下原廠資料為準，版本與頁碼應在每次供應商韌體更新後重新核對：

1. AN0701《SCS527E AT 指令手冊》：AT+IPR 約第 97–98 頁；AT+IFC 約第 102 頁。
2. AN0708《SCS527E CAT.1 芯片級模組應用指導／硬體使用手冊》：MAIN UART、RTS/CTS、預設速率與硬體能力約第 29–30 頁。
3. AN0714《SCS527E 應用指導：SSL & TLS》：TLS context、SSLOPEN、SSLSEND 的 1–1460 B 限制，以及 SSLURC recv/closed 約第 15–21 頁。
4. AN0715《SCS527E 應用指導：HTTP(S)》：HTTPPOST 的 4096 B header + body 預算、HTTPPOSTFILE 與 HTTPREAD 約第 17–20 頁。

如果供應商韌體、AT 文件或伺服器契約變更，應重新做同一套「原始資料 → 模組回顯 → 真機 HIL → 後端回執」鏈路，而不是只更新文章中的一個數字。

結語​

HTTP over TLS Socket 的價值不是把 AT 指令寫得更低階，而是把錄音上傳拆成一組可驗證的邊界：UART 只負責有長度的 byte stream，TLS 負責保密與伺服器身份，HTTP 負責請求語意，SHA-256 和冪等鍵負責資料身份，checkpoint 負責中斷恢復，後端 receipt 則負責告訴裝置「這一片到底是哪一片」。

在這個模型上，keep-alive、較大 chunk、較高 baud 和 RTS/CTS 都可以逐步測量、逐步回退；在模型之外，任何「201 就刪檔」「921600 已經可用」或「測試 TLS 等於量產 TLS」的捷徑，都只是把尚未解決的風險藏到下一次掉電、斷網或資料爭議裡。

版本： 1.1（PM／硬體規劃版） 資料截止： 2026-08-19（UTC+8） 適用範圍： 智能手錶、手環、戒指、耳掛／耳機、胸牌／卡片、吊墜、貼片、戶外穿戴與健康／運動穿戴

本文件是通用的智能穿戴傳感器調研，不針對任何單一品牌、晶片平台或既有產品工程。文中型號是用於建立選型池的代表性量產器件，不宣稱已覆蓋全球所有 SKU，也不等同於實機、人體或醫療驗證。

完整性口徑： 本版的「完整」是指在智能手錶、手環、戒指、耳掛／耳機、胸牌／卡片、貼片與戶外穿戴的適用範圍內，按物理量與產品模態覆蓋主要感測家族，並為每個家族提供可落地的代表器件、主機接口／資料協議、價格級別和工程風險；不是靜態窮舉全球每一家供應商的每一個 orderable SKU。罕見的實驗室、工業或醫療專用模態會在「邊界與未納入主 BOM」中標明，不能把代表性器件表誤讀成全球 AVL。

1. 執行摘要​

智能穿戴不是把多顆感測 IC 疊在同一張 PCB 上，而是「感測元件 + 光學／電極／聲學／天線結構 + 電源 + 韌體 + 演算法 + 驗證」的系統工程。最常見的錯誤，是把晶片資料手冊中的解析度、ADC 位數或「支援 HR／SpO₂／ECG」直接當成最終產品精度。

1.1 先按產品形態選感測器​

1.2 建議的產品分層​

1. 基礎互動層： IMU、霍爾、按鍵／電容觸控、麥克風、震動、電量計。
2. 環境與運動層： 氣壓、溫濕度、環境光、磁力計、ToF／接近。
3. Wellness 趨勢層： PPG、皮膚溫度、EDA／BioZ、單導聯 ECG；先定義為趨勢與生活方式資訊。
4. 連線與安全層： GNSS、NFC、UWB、Wi‑Fi／蜂窩、安全元件；每一項都需要天線、認證、供電和軟體服務配套。
5. 特殊環境層： VOC、PM、CO₂、汗液／電化學。這些不應只看 IC 單價，需把暖機、氣流、污染、校準、演算法與機構成本納入。

1.3 本文價格口徑​

• 價格以 2026-08-19 查到的公開原廠／分銷頁面或公開價格錨點為基礎，單位為美元。
• 表內「約」是用於立項、BOM 上限和 RFQ 優先級，不是採購承諾；裸 IC、模組、評估板的價格不能混用。
• 除非特別註明，價格不含 PCB、光學件、LED／光電二極體、電極、天線、晶振、匹配網路、電池、SMT、認證、演算法授權、雲服務和稅運費。
• 公開切帶／小批量價格通常高於 500／1k／10k 量產價；量產必須向原廠或代理商按 1k、10k、50k 重新 RFQ。

2. 感測器物理分類與可交付能力​

3. 主機接口與協議梳理​

3.1 接口不是應用協議​

設計文件必須分成兩層：

• 晶片與主控之間的接口： I²C、I3C、SPI、UART、PDM、I²S、ADC、GPIO。
• 空中或資料語義協議： BLE GATT、NMEA／UBX、ISO 14443／15693、NFC Forum、IEEE 802.15.4z、FiRa、Wi‑Fi AT 指令等。

例如，GNSS 可能用 UART 連到主控，但資料內容是 NMEA 或 UBX；NFC 讀卡器可能用 SPI 或 I²C 控制，但射頻側跑的是 ISO 14443、ISO 15693 或 FeliCa；UWB 常用 SPI 控制收發器，空中側則是 IEEE 802.15.4z／FiRa。把這兩層混寫，後續很容易誤判 MCU 是否「支援某協議」。

3.2 接口選擇表​

MIPI 將 I3C 定義為面向感測器與周邊的低功耗兩線控制總線，並強調 I²C 共存與 In-Band Interrupt；應以 MIPI I3C 官方頁面 和 I3C FAQ 為規格入口。I²C 電氣與時序應以 NXP UM10204 為基準，而非只照某一顆 sensor 的簡化範例。

3.3 音訊接口特別說明​

空氣聲／機身振動
        │
        ├─ 數位 MEMS 麥克風 ─ PDM／I²S ─┐
        ├─ 類比麥／壓電接觸拾音 ─ ADC ──┼─ DSP／主控
        └─ 多通道 Codec ─ I²S／TDM ──────┘

• PDM／I²S 傳的是採樣資料，不是「音訊理解協議」。
• VPU／接觸式拾音器不是固定的一種晶片。 它可能是壓電薄膜、陶瓷、接觸式麥克風、MEMS 加速度計或專用 AFE；接口可能是類比 ADC、PDM 或 I²S。
• 接觸式路徑能改善機械耦合下的抗環境噪聲能力，但必須在真實外殼、手機接觸面、風噪、敲擊與佩戴狀態下測試；它不會自動完成聲源分離、說話者識別或語音轉文字。

4. 代表性器件池​

4.1 運動、姿態與方向​

原廠資料： Bosch BMI270、Bosch BMM350、TDK ICM-42686-P、ST LSM6DSV16X、ST LIS2MDL。

選型重點： 如果主要功能是計步、敲擊和佩戴狀態，低功耗加速度計可能比完整 6 軸 IMU 更合理；如果要做姿態、旋轉手勢或聲學穩定，再加陀螺。磁力計必須在整機結構內重新校準，不能只在開發板上校準後照搬。

4.2 氣壓、高度與壓力​

原廠資料： Bosch BMP390、Infineon DPS310 datasheet、ST LPS22DF datasheet。

氣壓計感知的是絕對壓力，高度是由氣壓模型、海平面基準、溫度和時間濾波推導出來；室內空調、電梯壓差、衣物遮擋與防水膜都可能造成偏差。要把「爬樓層」作為功能，應以樓梯／電梯／戶外路線做 HIL 測試，而不是只驗證暫存器能讀到數值。

4.3 接觸與非接觸溫度​

原廠資料： MAX30208、STTS22H、MLX90632。

4.4 溫濕度、VOC、氣體與顆粒物​

原廠資料： SHT45、BME690、BME688／BME690 軟體、SGP41、SCD41、BMV080、SEN54。

結論：「環境感測」應拆成兩種產品：低功耗的微環境趨勢（溫濕度／壓力／光）和有氣流、暖機、污染管理的空氣品質節點（VOC／PM／CO₂）。不要把後者直接縮小成手腕健康傳感器。

4.5 環境光、UV 與光譜​

原廠資料： OPT3001、VEML7700、AS7331。

4.6 PPG、心率與血氧光學前端​

原廠資料： MAX86141、MAXM86161、AFE4950、Goodix GH3026、AS7058。

PPG 系統的最低設計清單：

1. LED 波長與光譜、峰值電流、占空比和電源瞬態。
2. 光電二極體面積、數量、串擾、遮光膠圈、窗口材料與厚度。
3. 皮膚接觸壓力、佩戴鬆緊、皮膚色調、毛髮、汗水與運動補償。
4. 板級地平面、LED 回流、模擬電源、數位時鐘和射頻共存。
5. 原始波形保存、演算法版本、資料標註、參考儀器、受試者分層與統計方法。

4.7 ECG、BioZ、EDA、呼吸與電化學​

原廠資料： MAX30001、AD5941、ADS1292R、LMP91000、ADuCM355。

必須分清三件事：

• ECG 是電位波形，不是 PPG 的另一個軟體模式。 需要兩個或多個電極、接觸、右腿驅動／參考和人體安全設計。
• BioZ／EDA 是激勵與測量系統。 外部電極材料、皮膚界面、電流密度、激勵頻率、濾波和溫度補償都會改變結果。
• 汗液／乳酸／葡萄糖等化學量不是「加一顆 AFE」就完成。 需要化學選擇性電極、微流道、校準、漂移控制和人體研究；產品主張應單獨走合規評估。

4.8 接近、ToF、霍爾、觸控與佩戴檢測​

原廠資料： VL53L5CX、VL53L5CX 原廠購買頁、DRV5032、FDC2214。

4.9 力、應變、壓電與接觸式振動​

這一類通常不是「一顆數位 sensor IC」，而是換能器 + 類比前端 + ADC + 機械結構：

接觸式 VPU 的正確定位： 它能提供一條與空氣麥不同的機械振動通道，對手機揚聲器經機身傳來的成分、敲擊或佩戴者自身振動可能有幫助；但是否能分離通話兩端、改善 SNR 或做語音活動判定，取決於整機的機械耦合、頻響、雙麥布置、DSP 和測試資料。不能從「接觸式」三個字推導出語義理解能力。

4.10 空氣麥克風、接觸拾音與音訊 Codec​

原廠資料： IM69D130、ICS-43434、TLV320AIC3204。TI 資料表明確把 Codec 的控制總線（I²C／SPI）與音訊總線（I²S／DSP／TDM）分開，這是多麥設計中常被忽略的接口層次。

4.11 GNSS、NFC、UWB、BLE、Wi‑Fi 與蜂窩​

這些嚴格說不是「被動環境傳感器」，但在智能穿戴產品中承擔位置、身份與資料連線，應與傳感器一起做系統選型。

原廠資料： MAX-M10 系列、MAX-M10S 資料表、ST25R NFC 讀寫器、Qorvo DW3110、nRF52840 規格、ESP32-C3-MINI-1 資料表、Quectel BG95。

4.12 供電、電量、安全與觸覺協同器件​

它們不是人體／環境傳感器，但會直接決定感測結果能否穩定取得，因此列入同一份選型手冊。

原廠資料： BQ27441-G1、BQ25155、ATECC608C、OPTIGA Trust M、SE050、DRV2605L。

4.13 影像、熱成像、毫米波雷達與顏色／光譜​

這一組器件容易被「一般穿戴 sensor 清單」漏掉，但在智能眼鏡、耳掛、胸牌、戶外安全穿戴和視覺交互產品中可能是核心。它們對鏡頭／視窗、ISP／DSP、散熱、資料儲存和隱私的要求，通常比一顆 I²C sensor 更高。

原廠資料： Sony 影像產品、Sony sensing image sensors、Sony IMX908、Melexis MLX90640、Infineon BGT60TR13C、ams OSRAM AS7341。

4.14 肌電、腦電、汗液電化學與推導型生理量​

EMG、EEG、EOG 是信號模態，不是一定對應某一顆專用 IC。工程上通常由電極、保護／偏置、低噪聲生物電位 AFE、ADC、同步時鐘和演算法共同實現；同一顆 AFE 可因電極位置、帶寬、增益和安全設計而承擔不同用途。

原廠資料： TI ADS1299、TI ADS1292R、ADI AD5941、TI LMP91000。

推導量的資料鏈要單獨建模： 原始波形、同步時間戳、電極／光學／機械條件、演算法版本、個體校準、參考儀器和誤差統計，至少要比「讀到一個數字」多一層證據。血壓、呼吸率、睡眠分期、體脂、水合、壓力等都應在需求文件中標為 derived metric，而不是把它們當成 sensor SKU。

4.15 直接壓力與系統電流／電壓監測​

直接壓力與電源監測在清單中常被混入「氣壓」或「電量」，但對袖帶、氣囊、堵塞檢測、電池安全和感測器峰值負載很重要。

原廠資料： Honeywell HSC、TE MS4525DO、TI INA219、TI INA228／INA238、TI BQ27441-G1。

5. 各形態的推薦組合​

5.1 卡片／夾式／胸牌​

推薦首版：

• 低功耗 6 軸 IMU 或加速度計：計步、翻轉、敲擊、活動事件。
• 數位 PDM 麥克風 + 可選接觸式振動通道：空氣聲與機械聲分路記錄。
• 霍爾：夾具、充電座、蓋合或佩戴狀態。
• 溫度／濕度／環境光：做微環境和使用狀態，不做醫療宣稱。
• 電量計、充電 PMIC、安全元件、震動與物理錄音指示。

不建議首版直接加入： PPG／ECG（沒有穩定貼膚界面）、PM／CO₂（體積、氣流、暖機、功耗）、GNSS／蜂窩（天線與峰值功耗會改變整機形態）。

5.2 手環／手錶​

推薦順序： IMU → PPG／皮膚溫度 → 氣壓／環境光 → 電極型 ECG／EDA／BioZ → GNSS／NFC／UWB。

PPG 光學窗口和電極要從 ID／MD 階段一起設計；把傳感器放在柔性排線上並不會自動解決皮膚壓力、遮光和自熱。GNSS、UWB、NFC 也不能共用同一套天線假設，需要獨立的 RF 佈局、匹配和認證計畫。

5.3 戒指／貼片​

優先低功耗、短距離、貼膚穩定的 PPG、皮膚溫度、EDA／ECG、IMU；把電池、充電、封裝、生物相容性、汗水腐蝕和電極壽命放在選型前面。對戒指而言，多顆高電流 LED、UWB、PM 和蜂窩通常比 IC 尺寸更先成為瓶頸。

5.4 耳掛／耳機​

空氣麥克風、接觸振動、IMU、磁力計和耳內溫度是最自然的組合。耳內 PPG 有穩定貼合優勢，但需要專用光學窗口、耳道位置、衛生和個體差驗證。接觸式振動可以做通話／VAD 輔助通道，但必須拿真實外殼、手機接觸面和不同佩戴姿態建立資料集。

6. 系統級設計風險​

6.1 光學風險​

• PPG 的有效訊號通常比環境光、運動干擾和 LED 直漏光小很多。
• 黑色遮光膠圈、窗口透過率、LED／PD 幾何、皮膚壓力和手腕曲率必須同時最佳化。
• LED 峰值電流會影響 PMIC、地彈、射頻和音訊底噪；要用示波器看真正的電源波形。
• 應保存 raw PPG，否則後續很難定位是光學、AFE、演算法還是傳輸丟包。

6.2 電極與人體電氣風險​

• ECG／EDA／BioZ 的電極材料、面積、間距、接觸壓力、汗水和皮膚阻抗決定訊號品質。
• 電極附近要做 ESD、漏電、充電狀態、人體接觸與故障電流評估。
• 「單導聯」只是導聯數量，不代表臨床診斷能力；使用者姿勢、接觸位置與參考電極都要寫入驗收條件。

6.3 溫度與氣壓風險​

• 溫度 IC 遠離 MCU、PMIC、LED、充電線圈和射頻功率器件；必要時做熱隔離槽或柔性延伸。
• 非接觸紅外溫度需要固定距離、視場、窗口和背景補償；人體表面溫度不是核心體溫。
• 氣壓計需要通氣孔和防水／防汗膜；膠水、泡棉、灰塵和服裝壓力會造成慢性偏差。

6.4 氣體、PM、CO₂ 風險​

• 金屬氧化物 VOC 方案常需要暖機和演算法；溫濕度、酒精、香水、清潔劑會造成交叉響應。
• PM 需要光路和空氣流動，雷射、光電二極體和污染管理會帶來機構與功耗成本。
• CO₂ 需要空氣交換；把感測孔貼在皮膚或衣物附近，讀到的可能是局部呼氣而不是環境值。
• 供應商提供的「Index」或「分類」不能不經校準直接改寫成 ppm 或健康指標。

6.5 IMU、磁場與機械風險​

• PCB 應力、焊接、外殼鎖螺絲、膠材和柔性板彎折會改變 IMU 偏置。
• 磁力計要做硬鐵／軟鐵校準，並在最終馬達、喇叭、磁吸、NFC 線圈和電池配置下重做。
• 「晶片內建步數／姿態」是演算法功能，不是完整產品驗證；不同佩戴位置要分開評估。

6.6 聲學與接觸振動風險​

• 空氣麥克風看的是聲壓；接觸式路徑看的是機械耦合，兩者的頻響、延遲和噪聲模型不同。
• 需要評估風噪、防水網、外殼聲孔、手指遮擋、衣物摩擦、敲擊和手機接觸面。
• 多麥陣列的「雙通道」不等於「雙聲道獨立內容」；真正的分離能力還需要陣列幾何、時鐘同步、回聲消除、波束形成或 source separation。

6.7 射頻與功耗風險​

• 人體、腕帶、金屬裝飾、電池和顯示窗口會讓天線失諧；天線驗證需在最終外殼和佩戴狀態下完成。
• PPG LED、UWB、GNSS、蜂窩、Wi‑Fi、振動馬達和 PM 雷射的峰值電流可能互相干擾。
• 量產前要有「傳感器 duty cycle → 峰值電流 → 電池壓降 → RF／音訊底噪」的完整電源模型。

6.8 供貨、生命週期與軟體依賴​

• Active、volume production、NRND、pre-production、out of stock 必須在 BOM 中分欄記錄。
• 原廠演算法、BSEC、PPG／SpO₂ library、NFC stack、UWB stack 可能有 NDA、授權或版本綁定。
• 把一顆器件換成同接口的替代料，通常仍會改變量程、FIFO、IRQ 極性、上電時序、校準和演算法輸入；不可只按封裝或 I²C 位址替換。

6.9 影像、熱成像、雷達與光譜風險​

• CMOS／ToF 影像需要鏡頭、濾光片、對焦／固定、MIPI CSI-2 接收、ISP／DSP、儲存頻寬和熱設計；影像資料還需要實體隱私指示、權限、加密與刪除策略。
• 熱成像陣列的像素是遠紅外輻射響應，和貼膚溫度 IC、紅外熱電堆單點溫度不是同一類證據；視場、距離、背景和窗口材料必須一起校準。
• 毫米波雷達輸出的通常是 IQ／range-Doppler／目標特徵，呼吸、存在或跌倒類功能是本地 DSP／演算法與資料集的結果；天線、射頻法規、人體遮擋和功耗要做整機驗證。
• 顏色／光譜 sensor 需要暗電流、光源、窗口、角度和溫度校準；通道 count 不能直接改寫成皮膚健康、血液或環境劑量。

6.10 生物電位、化學與推導量風險​

• EMG／EEG／EOG 的微弱訊號容易被運動、工頻、射頻、充電器和電極脫落污染；必須保存同步 raw data、導聯狀態和接觸阻抗。
• 汗液電化學量測的瓶頸通常在外部電極、微流道、分析物選擇性、汗液流量、污染與漂移，不在 AFE 的 ADC 位數；應將每一種分析物分開做方法學與人體驗證。
• 呼吸率、血壓、睡眠、體脂和水合等 derived metric 要同時驗證訊號鏈、演算法、參考儀器、族群、個體校準和失效輸出，不能只驗證 API 回傳非空。
• 直接袖帶壓力 sensor 仍需要泵、閥、袖帶／氣囊、洩壓與安全設計；它和「無袖帶血壓估計」是兩條不同的產品路徑。

7. 健康、醫療與隱私邊界​

7.1 Wellness 與醫療不是同一個級別​

可以先把產品輸出定義為「活動、睡眠習慣、心率趨勢、皮膚溫度趨勢、環境暴露」等一般健康資訊；若輸出涉及疾病診斷、急救、治療決策、醫療告警或醫療級數值，就需要重新評估 intended use、臨床證據、風險管理、品質系統和地區法規。

FDA 2026 年的 General Wellness 指引針對低風險、促進健康生活方式且不涉及疾病診斷／治療的產品提供政策說明，仍不代表任何特定傳感器或演算法自動獲得醫療資格，請參考 FDA General Wellness: Policy for Low Risk Devices。

7.2 不把無創血糖列為普通穿戴功能​

FDA 已明確警告：不要使用宣稱可在不刺破皮膚的情況下測量血糖的智能手錶或智能戒指；FDA 表示並未授權、批准或核准任何可自行測量或估算血糖的智能手錶／戒指。參考 FDA Safety Communication。

7.3 隱私要求​

• 原始音訊、PPG、ECG、EDA、位置、設備身份和生物特徵應分級存取。
• 應明確區分「本地暫存」「同步傳輸」「雲端處理」「模型訓練」和「使用者刪除」。
• 錄音／生理資料的指示燈、實體按鍵、配對確認、加密、權限和審計記錄應在產品需求階段凍結。
• 安全元件解決的是金鑰與身份保護，不會自動解決錄音合法性、使用者同意或醫療合規。

8. 建議的通用開發階段與 BOM 閘門​

P0：基礎互動與可靠資料​

建議器件池： BMI270／BMI323／LSM6DSV16X 三選一；DRV5032；IM69D130；MAX30208 或 TMP117；BQ27441；BQ25155；ATECC608C／OPTIGA Trust M；LRA + DRV2605L；必要時 OPT3001。

通過條件：

• 低功耗待機、喚醒、計步／敲擊、錄音、音訊資料完整性、電量估計和充電溫升可重複。
• 任何原始音訊／感測資料都有時間戳、丟包／校驗和明確的資料刪除策略。
• 供應商可提供正式料號、封裝、PCN／EOL 路徑和 1k／10k RFQ。

P1：環境與近場互動​

建議器件池： BMP390／BMP580／LPS22DF；SHT45；VEML7700；ST25DV-I²C 或 ST25R3916；必要時 VL53L1X／VL53L5CX。

通過條件：

• 通氣孔、防水膜、窗口、磁吸和外殼裝配完成後，氣壓、溫濕度、ALS、NFC／ToF 仍達到產品需求。
• I²C 位址、I3C／I²C 共存、SPI CS、IRQ、上拉與睡眠喚醒圖已凍結。

P2：Wellness 趨勢​

建議器件池： MAX86141／MAXM86161／AFE49I30／GH3026／AS7058；MAX30208／TMP117；若確有電極形態，再評估 MAX30001、ADS1292R、AD5941。

通過條件：

• 光學堆疊／電極／機構樣件先於軟體演算法凍結。
• 在不同膚色、佩戴鬆緊、運動強度、環境溫度和充電狀態下取得 raw data。
• 明確把「晶片規格」「工程樣機指標」「人體研究」「醫療宣稱」分成四份證據，不能混寫。

P3：戶外與連接擴展​

建議器件池： MAX-M10N／MAX-M10S；DW3110／DW3120；NFC；BLE／Wi‑Fi 協處理器；BG95 等蜂窩模組。

通過條件：

• 最終外殼、佩戴狀態、天線、匹配、共存、電池峰值和認證方案完成。
• GNSS 冷／暖／熱啟動、UWB 兩端兼容、NFC 讀距、BLE／Wi‑Fi 共存和 OTA／安全更新都有測試記錄。

9. 驗證與驗收矩陣​

10. RFQ 與供應商問卷​

每一顆列入 AVL 前，至少向原廠／代理商索取：

1. 完整 orderable part number、封裝、溫度等級、MSL、RoHS／REACH。
2. Active／NRND／EOL 狀態、PCN／PDN 通知週期、最後一次資料表版本。
3. 1k／10k／50k 價格、MOQ、交期、產地、替代料和安全庫存建議。
4. 評估板、driver、SDK、演算法庫、授權條款、NDA、版本相容性。
5. 上電／reset／休眠／中斷時序、I²C 位址、SPI mode、I3C 相容性。
6. 峰值電流、平均電流、LED／雷射／加熱器／暖機條件和電源噪聲要求。
7. 對光學件、電極、天線、氣流、窗口、膠材、校準和機械尺寸的依賴。
8. 是否有客戶可公開的 reference design、量產測試方法和失效分析邊界。
9. 對健康／醫療相關器件，不只問「是否 medical grade」，還要問適用的 intended use、認證範圍和可引用證據。

11. 結論​

對多數智能穿戴，最穩妥的工程順序不是一次集成全部功能，而是：

1. 先用 IMU、麥克風、霍爾、溫度、電量、震動和安全元件建立可靠底座。
2. 再加入氣壓、溫濕度、環境光、NFC／ToF 等對機構要求可控的環境／互動器件。
3. 只有在佩戴形態、光學窗口、電極和資料採集方法確定後，才加入 PPG、ECG、EDA／BioZ。
4. GNSS、UWB、Wi‑Fi、蜂窩、PM、CO₂ 和電化學傳感器應以獨立系統工程評審，不要按「多一顆 IC」估算。
5. 所有健康輸出先按 wellness 趨勢定義；任何診斷、急救、疾病預警或醫療級主張，都必須另建法規、臨床和風險管理路徑。

這份器件池可作為下一輪原理圖、板級 Adapter、機構樣件、BOM 成本上限和供應商 RFQ 的共同入口；正式定案前，仍需對目標地區、最終外殼、真實電池、天線、人體樣本、演算法授權和量產測試重新核驗。

11.1 完整性邊界與後續維護​

經本輪補查後，本文已按智能穿戴的主要物理量／產品模態補齊：運動與方向、壓力與高度、接觸／非接觸溫度、溫濕度、VOC／NOx／CO₂／PM、環境光／UV／顏色／光譜、PPG、ECG、BioZ／BIA、EDA、EMG、EEG、EOG、汗液電化學、影像／ToF、熱成像、毫米波雷達、力／應變／壓電、空氣／接觸音訊、GNSS、NFC、UWB、BLE／Wi‑Fi／蜂窩，以及電量／電流／電壓／安全／觸覺協同器件。這個層級可以稱為類別完整、選型可落地。

仍然不能把它描述成「全球所有型號全部列完」：供應商的新料號、區域封裝、模組、客製化汗液／醫療探頭、超聲／超音波成像、電離輻射等少量或研究型模態會持續變化；它們應作為獨立的 emerging／medical／industrial 清單按產品形態追加。價格、庫存、生命周期、NDA、演算法授權和法規狀態也不是一次寫入後永久有效，應由 AVL／RFQ 表持續維護。

因此，本版可以作為博客的完整調研基線發布；若要形成可下單的 BOM，下一步仍必須把目標形態、量產數量、地區法規、封裝、實際供貨和第三方驗證結果再篩選一次。

附錄 A：主要公開資料入口​

• MIPI I3C／I3C Basic
• NXP I²C-bus specification UM10204
• Bluetooth Core Specification — GATT
• Bosch Sensortec Wearables
• ST MEMS and sensors
• Analog Devices wearable／vital signs products
• Texas Instruments sensors
• Sensirion environmental sensors
• ams OSRAM wearable vital sign monitoring
• Sony Semiconductor image sensors
• Melexis MLX90640 far-infrared array
• Infineon XENSIV BGT60TR13C radar
• ams OSRAM AS7341 spectral sensor
• Honeywell TruStability HSC pressure sensors
• TI INA219 current／power monitor
• TI INA238 current／voltage／power monitor
• Microchip ATECC608C
• FDA General Wellness policy
• FDA smartwatches／rings blood glucose safety communication

資料狀態聲明： 價格、庫存、生命週期、資料表版本和授權條款都會變動。下單、打樣、投板或對外發布前，應重新打開原廠頁面和最新 datasheet 核對，並取得書面 RFQ。

很多錄音卡、耳機和智慧穿戴產品都開始出現 VPU、Vibration Conduction Sensor、Voice Vibration Sensor 或 Bone-Conduction Microphone 這些名稱。它們都指向一個很有吸引力的想法：不要只用空氣麥克風收音，而是直接接觸人體、耳機或手機外殼，從固體的振動中取出語音。

但「VPU 能不能知道電話另一端說了什麼」不能用一句「可以」或「不可以」回答。它不是手機通話資料介面，也不是能夠解碼 Android 通話的特殊晶片；它是一個機械振動感測器。當電話聽筒或揚聲器把遠端聲音轉成手機外殼的結構振動，並且感測器與外殼之間有足夠好的機械耦合時，接觸式感測器才可能從這條路徑取得遠端語音。

本文把「人體骨傳導拾音」、「手機外殼接觸式拾音」、「一般接觸式麥克風」和「寬頻振動加速度計」分開討論，並把產品宣稱、資料手冊、論文、專利和實際工程證據分層。重點不是把所有產品都叫成同一種 VPU，而是回答以下問題：

1. 不同器件真正感測的是什麼？
2. 它們適合收自己的聲音、電話另一端，還是只適合做振動事件偵測？
3. 為什麼接觸式訊號通常抗風噪，卻又容易悶、失真、對安裝方式敏感？
4. 錄音卡應該選類比 VPU、PDM 數位 VPU，還是先用壓電接觸片做概念驗證？
5. 哪些論文與開源專案可以直接轉成下一輪硬體與 DSP 實驗？

:::info 先給結論

• 在耳機、耳塞或喉部佩戴場景，VPU 的主用途通常是拾取「佩戴者自己的聲音」，用來抗風、抗環境噪聲、做自聲 VAD、通話上行增強或語音驗證。
• 在手機背面錄音卡場景，接觸式感測器確實可能拾取遠端聲音，但前提是手機聽筒／揚聲器到手機機身再到感測器的機械傳遞路徑成立。這是特定手機、音量、位置、外殼和接觸壓力共同決定的結果，不是 VPU 的普遍能力。
• 空氣麥克風與 VPU 的最佳分工通常是互補：空氣麥克風保留自然頻寬與周圍聲音，VPU 提供低環境噪聲的結構振動參考；最後仍要靠同步、校準、融合和語音增強。
• 目前 Hera Pro 來源中的錄音路徑是單聲道類比麥克風、16 kHz、MP3。加入 VPU 不是換一顆麥克風就完成，而是要同時檢查感測器介面、ADC／PDM 資源、機械結構、雙通道同步和 DSP。

:::

1. 先把名詞分清楚​

1.1 VPU 不是一種唯一的元件結構​

VPU 常被展開為 Voice Pick-Up、Voice Pick-Up Unit 或 Voice Vibration Sensor。它描述的是用途與訊號路徑，不一定對應唯一的 MEMS 結構。不同供應商可能把下列幾種器件都放在 VPU、骨傳導麥克風或振動感測器分類下：

因此，本文在提到「VPU」時，若沒有特別說明，指的是面向語音拾取的接觸式振動感測器；提到「手機背面 VPU」時，則是指把這類器件用在手機外殼結構振動上的特殊應用。

1.2 「骨傳導」在人體和手機上不是同一條路​

耳機中的骨傳導拾音，通常是：

聲帶與喉部運動
    ↓
皮膚、軟組織、骨骼的機械振動
    ↓
貼合耳周、顴骨或喉部的 VPU
    ↓
低環境噪聲的自聲訊號

手機背面錄音則是另一條結構傳遞鏈：

遠端語音的數位通話資料
    ↓
手機音訊編解碼器與聽筒／揚聲器
    ↓
空氣聲壓 + 手機框架、背板、玻璃的結構振動
    ↓
磁吸／膠黏／硬接觸結構
    ↓
接觸式感測器

第二條鏈路沒有經過錄音卡的 Android 音訊 API。錄音卡只是自己量測手機外殼的振動，所以它不能讀出通話編碼、不能繞過 Android 權限，也不能保證在藍牙耳機通話時還有足夠的手機外殼振動。

2. 工作原理：為什麼它能抗風，又為什麼聲音會變悶​

2.1 空氣聲和結構聲是兩個不同的通道​

把說話者的語音記為 s(t)，空氣麥克風可以粗略寫成：

x_air(t) = h_air(t) * s(t) + n_air(t)

其中 h_air 是空氣、外殼、麥克風方向性和前端共同形成的傳遞函數，n_air 是風噪、環境聲、碰撞聲和電子噪聲。

接觸式感測器量到的不是同一個聲壓，而是接觸位置的結構振動。對人體自聲可寫成：

x_vpu(t) = h_body(t) * v_body(t) + n_contact(t)

對手機背面電話錄音則更接近：

x_contact(t) = h_phone(t) * v_phone(t) + n_contact(t)

v_body 或 v_phone 是由人體或手機機身傳到感測器的振動。這裡的抗風能力不是演算法憑空製造的，而是因為風主要先作用在空氣麥克風的聲學入口，未必能以相同幅度進入人體或手機背板的結構通道。

實際產品還有三個難點：

1. 空氣通道和結構通道的頻率響應不同，不能只把兩路波形相加。
2. 兩個感測器的延遲、相位、增益和安裝方向不一定一致。
3. 機械接觸本身會引入手指摩擦、敲擊、殼體共振和壓力變化。

2.2 為什麼 VPU 常常「抗噪但不自然」​

人體、膠黏層、手機玻璃和塑膠外殼都會形成機械低通或共振。高頻諧波比低頻更容易在傳遞過程中衰減，因此直接播放 VPU 原始訊號時，常見的主觀感受是：

• 音色偏悶，子音、擦音和齒音不完整；
• 說話人身份或語意仍然可能保留，但音質不如空氣麥克風；
• 不同佩戴者、不同接觸壓力和不同手機型號，頻譜差異很大；
• 如果把 VPU 當成完整的獨立錄音麥克風，結果常比宣傳示範更不穩定。

2018 年的 Interspeech 論文直接把這個取捨說得很清楚：骨傳導感測器相對不受環境噪聲影響，但 4 kHz 以上的高頻成分會明顯衰減，原始 BC 訊號通常不適合直接使用，卻很適合作為空氣麥克風的噪聲估計輔助。這比「VPU 完全取代空氣麥克風」更接近工程現實。

2023 年 Sensors 論文的原型也採用了 V2S100D PDM 骨傳導麥克風、類比空氣 MEMS 麥克風和 BES2300YP 控制器，並用神經網路做音訊超解析度。這條路線的核心不是假裝感測器本身頻寬很寬，而是利用配對的空氣／骨傳導資料重建被機械通道濾掉的中高頻。

2.3 手機背面為什麼有機會錄到遠端語音​

在一般手機聽筒通話中，遠端語音先由手機上方的聽筒輸出。即使人耳是主要接收者，聽筒及其固定結構仍可能把一部分能量傳入中框、螢幕、背板或內部支架。免持模式則由揚聲器輸出更大的空氣聲和機械能量，通常更容易在機身上形成可測的振動。

如果錄音卡同時具備以下條件，接觸式通道就可能留下可辨識的遠端語音：

1. 感測器接觸在振動能量較高的位置；
2. 感測器和手機背板之間沒有被泡棉、厚軟殼或鬆動磁吸層隔開；
3. 磁力或機械壓力穩定，不會因手持姿勢而浮動；
4. 手機音量、聽筒／揚聲器狀態和手機結構允許這條傳遞路徑；
5. 後端對感測器的頻響、噪聲和失真做了校準。

這也是為什麼市場上的電話錄音卡通常要求磁吸貼在手機背面，並把「Vibration Conduction Sensor」作為獨立電話模式，而不是宣稱卡片在桌上放著就能收取遠端通話。

2.4 VPU 可以知道「對面說什麼」嗎？​

更精確的回答是：

VPU 可以量到包含遠端語音資訊的機身振動；它不是直接知道對方說了什麼，而是先取得一個經過手機機械傳遞、頻寬受限且可能混有本機噪聲的類比或數位振動訊號，後端再把訊號當作音訊處理。

如果電話使用藍牙耳機，手機的聽筒或揚聲器可能沒有播放遠端聲音，手機背板上的可用振動就可能大幅下降。若使用手機免持，通道可能變強，但空氣麥克風也會同時收到房間聲、回授和自己的聲音。若手機套很厚、磁吸位置偏離、接觸面有軟墊，結果也可能改變。

所以，電話另一端的「可懂度」必須用實際手機、實際外殼和實際安裝方式測量，不能從 VPU 型號名稱推導出來。

3. 商用產品與市場做法​

3.1 耳機和穿戴裝置：VPU 的主流用途是自聲​

Sonion 官方 Sensors 頁面把這類產品定位為特殊耳機、耳塞和耳機中的 voice-pick-up bone sensor，並把產品分成 vibration sensor、bone conduction vibrator 和 voice pick-up sensor。官方公開頁面給出的重點是「小尺寸、自己的聲音偵測、高 SNR」，完整料號與電氣規格需要向供應商索取。

Syntiant V2S 官方頁面則把 V2S200D／V2S200DZ 定位成數位語音振動感測器，公開列出 PDM 介面、64.5 dB SNR、±25 g、10 kHz 頻寬、1.8 V 供電，以及耳機、穿戴裝置、自聲偵測、風噪抑制和 imposter rejection 等用途。它也有汽車和工業版本，說明這類感測器不只服務人體語音，也可以用來量測結構聲和機械故障。

這些產品的共同點是：感測器要壓在人體或設備的振動路徑上。它們不是把空氣聲「隔空變成」骨傳導，而是利用機械耦合改變信噪比。

3.2 錄音卡：把 VPU 放在手機背面​

目前公開市場已經能看到多個「卡片式 AI 錄音器 + 手機電話模式」的產品。這些產品頁不是獨立實驗室報告，因此應當視為市場與產品形態證據，而不是對所有手機的效能保證。

Plaud 的支援文件明確寫出，電話模式需要把裝置貼在手機背面，讓內部 vibration conduction sensor 直接取得手機揚聲器相關的振動；它也說明使用耳機時不支援同一種電話 VCS 路徑。這正好印證了「感測器不是讀通話資料，而是依賴手機的物理播放路徑」。

3.3 專利與商用宣稱要分開看​

EP4513485A1 Smartphone Recorder 和對應的 US20250184420 公開了把壓電感測器貼在智慧型手機背面、讀取通話期間由手機後表面傳出的振動資料，再轉成語音資料的方案。專利可以證明這是一條被工程師正式提出、具備機械結構與電路實施描述的路線，但專利權利項本身不等於所有手機都能得到相同清晰度。

最重要的產品設計訊息有兩個：

• 感測器的感測面必須和手機背面形成可靠接觸；
• 磁鐵、膠帶、外殼、支撐板和感測器位置本身就是訊號鏈的一部分。

4. 元器件與產品選型​

以下資料以 2026 年 8 月公開頁面為準。供應狀態、料號後綴、資料手冊版本和代理商庫存會變化；真正進入 BOM 前要重新索取原廠資料手冊、樣品和 PCN。

4.1 數位 VPU：PDM 介面​

Syntiant 官方還提供 Application Notes，其中分別討論 consumer body vibration speech pickup、sound-induced vibration 和 predictive maintenance。這些資料對安裝位置、訊號處理與測試方向比單一「SNR」數字更有價值。

4.2 類比 VPU：適合先驗證錄音卡概念​

類比器件對現有類比麥克風系統較容易做概念驗證，但仍然要確認：

• 麥克風輸出是偏壓類比、差動類比還是單端類比；
• 輸出直流電位、輸出阻抗、最大加速度和失真；
• ADC 的輸入共模、偏置、增益和抗混疊濾波；
• 是否需要高通去除 DC、低通限制頻寬和額外的機械保護。

4.3 接觸式壓電與舊型加速度感測器：適合 PoC，不一定適合量產​

CM-01B 的優點是容易得到「固體振動」的直觀結果，缺點是供電、尺寸和低通特性不一定適合錄音卡。裸壓電片則可以快速回答「手機背面是否有可用振動」，但不能直接代表量產 VPU 的信噪比和頻響。

4.4 選型建議​

如果目標是 Hera Pro 錄音卡的第一輪工程判斷，可以按以下順序取得樣品：

1. PUI VMM-1627L-R 或同級類比 VPU：先走現有類比音訊路徑，快速確認人體與手機背面是否有有效訊號。
2. Syntiant V2S200DZ 評估套件：用來比較真正 PDM 數位 VPU 的頻寬、抗環境噪聲和薄型安裝可能性。
3. 裸壓電片或 CM-01B：只做桌面／手機機身結構傳遞的物理概念驗證，不把結果當成量產規格。
4. Sonion 客製 VPU：在機械結構、聲學目標和月用量清楚後，再走 FAE、樣品、封裝和可靠度評估。
5. VA1200、LIS25BA 等 EOL 器件：只用於學術重現或已有庫存，不作為新設計的首選。

5. 硬體整合：真正決定效果的是「機械 + 類比 + 數位」三件事​

5.1 機械結構不是外觀件，而是前端濾波器​

對手機背面錄音卡而言，感測器、膠黏層、磁鐵、支撐板、手機外殼和背板共同構成一個機械濾波器。至少要控制以下變數：

• 接觸位置：不同手機的聽筒、揚聲器、電池、支架和背板厚度不同；同一個卡片位置不會得到相同頻響。
• 接觸壓力：壓力過小會失去低頻和穩定性，壓力過大會把手持噪聲和殼體應力帶進來。
• 接觸材料：泡棉和厚軟殼可以隔振，薄硬支撐或直接硬接觸通常更容易傳遞結構聲，但也可能增加刮傷與碰撞。
• 安裝方向：單軸 VPU 具有方向性，感測軸要和目標結構振動方向做實驗匹配。
• 應力與線纜：排線拉力、焊點、膠水收縮和外殼變形都可能比語音訊號更大。
• 共振：卡片殼體或磁吸結構的共振峰可能被誤認為遠端語音頻帶。

推薦先製作可替換感測器的機械治具，固定手機型號、位置、壓力和卡片姿態，再比較器件，而不是先把感測器封進量產外殼。

5.2 類比 VPU 的前端​

類比 VPU 的基本鏈路通常是：

VPU
  ↓
直流偏置／AC 耦合
  ↓
低噪聲增益或 PGA
  ↓
高通／低通／抗混疊
  ↓
ADC
  ↓
同步 PCM

需要注意三個常見錯誤：

1. 把資料手冊中的 dB、dBV/g、dBFS/g 混在一起比較；
2. 看到輸出阻抗很低，就以為不需要偏置、耦合和濾波；
3. 只錄 MP3，不保存原始 PCM，導致無法判斷是感測器、ADC、AGC 還是編碼器造成的失真。

第一輪實驗最好保存 16-bit 或 24-bit 原始 PCM，固定增益、關閉不必要的 AGC，並同時保存空氣麥克風和接觸通道。

5.3 PDM／TDM VPU 的前端​

PDM VPU 不是「數位麥克風插上就有 WAV」。需要處理：

• PDM clock 頻率、資料邊沿和左右／多感測器選擇；
• PDM decimation、抽取濾波和輸出採樣率；
• 介面時鐘與空氣麥克風 ADC 是否同源；
• 低功耗模式時的啟停、settling time 和遺失樣本；
• MCU 的 DMA、RAM、CPU 負載和錄音同步。

TDM 加速度計又是另一種介面：它可能輸出多軸振動資料，但並不等於音訊 codec 的 PCM 介面。需要先閱讀完整資料手冊，確認每一個 TDM slot、資料格式、時鐘主從關係與有效頻寬。

5.4 Hera Pro 的目前工程邊界​

從目前 Hera Pro 的來源來看，錄音程式以 SDK 類比麥克風作為 AUDIO_STREAM_AI 輸入，設定為單輸入、單輸出，並以 16 kHz、16 bit、mono 進入 MP3 錄音。這代表：

• 類比 VPU 可以作為第一個「是否有物理可用訊號」的候選，但仍要確認板級 ADC 輸入、偏置和硬體走線；
• PDM V2S 需要新增或確認 PDM clock/data 資源，不是把類比 MIC 型號替換成 PDM 型號；
• 如果要同時保存空氣麥克風與 VPU，capture_channels_input = 1 的單通道架構必須重新評估；
• 若只把兩路在 ADC 前混成一路，後續很難做電話模式、會議模式和融合演算法的比較；
• 這篇調研不代表 Hera Pro 已經完成 VPU 硬體、韌體或實機驗證。

對錄音卡來說，最有價值的第一版不是「馬上輸出最漂亮的 MP3」，而是可以重複取得 air.wav、vpu.wav、mixed.wav 三組對齊資料。

6. DSP 與 AI：VPU 通常是輔助通道，不是萬能主通道​

6.1 四個基本處理階段​

一個可重複的雙通道處理鏈可以分成：

1. 同步：兩路使用同一時間基準，校正固定延遲與樣本偏移。
2. 校準：量測每一路的增益、噪聲底、頻響和安裝方向。
3. 通道分工：空氣麥克風保留自然語音，VPU 用於自聲、接觸聲或噪聲參考。
4. 融合／重建：以傳統 DSP 或模型產生電話錄音、通話上行或語音辨識需要的訊號。

6.2 傳統 DSP 路線​

最簡單的頻域融合可以寫成：

Y(f) = W_air(f) X_air(f) + W_vpu(f) X_vpu(f)

但 W_air 和 W_vpu 不能固定寫死。它們會受到手機型號、接觸位置、佩戴者、音量、外殼和當下動作影響。更穩妥的做法是：

• 用 VPU 的高信噪比區段輔助 VAD；
• 用 VPU 估計空氣麥克風的噪聲功率譜；
• 在不同頻帶採用不同權重；
• 用自適應濾波或 Wiener／MMSE 估計，而不是直接相加；
• 在電話模式與會議模式使用不同的通道策略。

Interspeech 2018 的 Bone-Conduction Sensor Assisted Noise Estimation正是把 BC sensor 當作噪聲估計輔助，而不是直接拿 BC 原聲取代 AC mic。這個思想很適合第一版錄音卡，因為它不要求 VPU 產生完整自然音色。

6.3 神經網路路線​

常見方向有三種：

• 頻寬擴展／音訊超解析度：從低頻、低頻寬的 VPU 估計被機械傳遞濾掉的中高頻；
• AC/BC 多模態融合：在複數頻譜或時域中共同估計乾淨語音；
• 自聲 VAD／語音驗證：只使用 VPU 的高隔離特徵判斷「本人是否在說話」，再控制空氣麥克風或上行鏈路。

神經網路不能彌補不存在的物理訊號。如果手機背面幾乎沒有遠端語音振動，模型很可能只是在重建訓練資料中的平均音色，造成幻覺式音訊或錯誤字詞。模型必須用與目標機械結構相同的配對資料訓練或微調。

7. 論文、資料集與專利地圖​

7.1 直接相關的研究​

7.2 手機電話錄音相關專利​

7.3 公開資料集​

Vibravox 的論文摘要與現行專案頁面對資料量的統計口徑不完全相同：論文摘要寫 38 小時，專案頁面列出 45.5 小時。這是資料版本／整理口徑的差異，使用時應以具體 release、Hugging Face dataset card 和引用版本為準。這種差異也提醒我們：做模型比較時必須鎖定資料集版本，而不是只引用一個總時數。

8. 開源專案：哪些可以直接用，哪些只是研究材料​

目前沒有一個成熟、開源、可以直接把「手機背面 VPU + 任意 Android 手機」變成量產電話錄音卡的完整專案。可用資源主要分成三層：VPU 語料與模型、可重現的研究平台、通用音訊 DSP。

8.1 直接與 body-conduction／AC-BC 相關​

8.2 通用音訊 DSP 與邊緣部署元件​

開源資源的正確使用方式是：

先錄製自己的 air.wav + vpu.wav
        ↓
用 ABCS／ESMB／Vibravox 做演算法概念與訓練方法參考
        ↓
用 RNNoise／DeepFilterNet 做空氣通道基線
        ↓
用 EBEN／DBMIF／自建小模型做 AC/BC 融合或頻寬擴展
        ↓
在目標 MCU 上用 CMSIS-NN 或原生 DSP 做量化與移植

不能反過來拿一個在人體喉音資料上表現很好的預訓練模型，直接宣稱它可以處理手機背面的遠端電話聲。

9. Hera Pro 錄音卡的建議開發路線​

P0：先驗證物理通道，不改產品承諾​

目標是回答「手機背面是否存在足夠可用的結構語音」，不是先追求最終音質。

1. 準備一個可更換 VPU 的硬體治具，同時放置空氣麥克風與接觸感測器。
2. 優先比較一顆類比 VPU、一個 Syntiant V2S 評估套件和一片裸壓電接觸片。
3. 同一支手機固定位置，分別測無殼、薄殼、厚殼、磁吸環、不同壓力。
4. 分別測正常聽筒、免持揚聲器、不同音量、不同手機型號和藍牙耳機。
5. 保存原始同步 WAV，不要只保存 MP3；每個檔案記錄手機型號、模式、位置、壓力和音量。

P1：先做兩路離線分析​

最小資料格式可以是：

session.json
air.wav       16 kHz / 16 bit / mono
vpu.wav       16 kHz / 16 bit / mono
mix.wav       可選的融合結果
notes.txt     手機、外殼、接觸位置、音量、噪聲與失敗原因

先做以下圖表和指標：

• 空氣與 VPU 的 RMS、峰值、噪聲底和 clipping 比例；
• 兩路的短時頻譜、互相關、固定延遲和頻率響應；
• 遠端語音的 segmental SNR、STOI、PESQ 或 MUSHRA；
• 固定 ASR 模型的 WER／CER；
• 本人語音、遠端語音、手指敲擊、桌面摩擦和風噪的分類混淆；
• 不同手機和外殼的跨裝置泛化。

P2：再決定類比或 PDM​

P3：韌體與 Android 的責任邊界​

VPU 的音訊在錄音卡內由感測器、ADC／PDM、DSP 和編碼器產生。Android 應用程式通常只負責：

• 開始／停止錄音、選擇會議或電話模式；
• BLE 控制和狀態回報；
• 下載原始或 MP3 檔案；
• 在手機端做轉寫、摘要、標註和檔案管理。

Android 不會因為存在 VPU 就取得通話內部 PCM。若產品需要「電話模式自動判斷」，可以由接觸振動、空氣通道、按鍵或 Android 顯式狀態共同決定，但要把它當成產品狀態機，而不是 Android 通話資料介面。

10. 最容易踩到的坑​

坑一：把「骨傳導」理解成「能聽到對方」​

耳機 VPU 的最典型對象是佩戴者自己的聲音。手機背面遠端語音是另一個特殊機械傳遞問題，必須另外測。

坑二：把供應商的「抗噪 40–50 dB」當成系統 SNR​

這類數字可能是特定頻率、特定加速度、特定安裝和特定聲學條件下的隔離度，不等同於完整錄音卡在所有語句、手機和外殼上的 WER 或可懂度。

坑三：用一個漂亮頻譜圖就宣稱成功​

手機機身共振、手指碰撞、AGC、MP3 編碼和 FFT 窗口都可能產生漂亮峰值。要用配對錄音和語音指標驗證，並保留原始通道。

坑四：只看感測器，不看機械治具​

同一顆 VPU 裝在耳塞、硬質耳機、薄卡片和厚手機殼上，可能得到完全不同的結果。機械結構是產品的一部分，不是裝配細節。

坑五：把通用降噪模型當成 VPU 融合模型​

RNNoise、DeepFilterNet 和 WebRTC APM 都很有用，但它們不能自動知道哪一路是結構聲、哪一路是空氣聲。AC/BC 融合需要同步資料、傳遞函數或針對目標 sensor domain 的模型。

坑六：忽略錄音法律與隱私​

電話錄音是否需要對方同意、是否能跨地區使用，取決於司法管轄、產品市場和使用場景。硬體能錄到，不代表產品就可以不提示、不告知或不保留操作記錄。

11. 最終判斷​

VPU 的價值不是「多一顆神奇麥克風」，而是多建立一條和空氣聲不同的機械訊號通道：

• 對耳機和穿戴裝置，它主要讓佩戴者自己的語音在風噪、車流和嘈雜環境中更容易被辨識；
• 對會議錄音，它可以作為自聲／接觸聲輔助，但空氣麥克風仍是自然環境聲的主通道；
• 對手機背面電話錄音，它有機會從手機聽筒或揚聲器造成的外殼振動取得遠端語音，這條路線已有商用產品和專利，但必須做手機、外殼、接觸壓力和模式的實測；
• 對工業、聽診器和機械聲，它也可以是結構振動感測器，不必局限於語音。

如果要把它落到 Hera Pro，合理的第一步是「類比 VPU + 空氣麥克風雙路原始錄音 + 可重複機械治具 + 手機矩陣測試」。先把遠端語音在接觸通道中的存在性、可懂度和跨手機穩定性量出來，再決定 PDM、模型、外殼和量產 BOM。只有這樣，才能把「VPU 能不能錄到對面」從市場宣稱變成可審核的工程結論。

12. 參考資料入口​

產品與器件​

• Syntiant V2S Voice Vibration Sensor
• Syntiant V2S Application Notes
• PUI VMM-1627L-R
• Sonion Sensors
• TE CM-01／CM-01B
• Vesper VA1200 datasheet
• ST AIS25BA
• ST LIS25BA

商用產品與電話錄音形態​

• Plaud hardware comparison
• Plaud Note Pro product page
• Plaud phone call recording explanation
• Suisse Notes Pro
• OEQ AI Voice Recorder

論文、資料集與開源程式​

• Interspeech 2018：BC sensor assisted noise estimation
• Sensors 2023：On-chip audio super resolution
• EBEN paper／EBEN code
• TRAMBA
• Vibravox paper／Vibravox code
• ABCS corpus
• ESMB corpus
• DBMIF code
• OpenSpeechPlatform
• RNNoise
• DeepFilterNet
• WebRTC Audio Processing

手機結構振動與專利​

• EarSpy
• Vibration Sensitivity of one-port and two-port MEMS microphones
• EP4513485A1 Smartphone Recorder
• US20250184420 Smartphone Recorder

本文的產品規格、供貨狀態與開源專案狀態都應在下單、打樣或發布韌體前重新核對；產品頁面能證明「供應商如何定位器件」，論文能證明「在特定資料與裝置上做過什麼」，只有目標手機、目標外殼和目標錄音卡的配對實驗，才能證明 Hera Pro 的實際效果。

这篇文章记录一次从“让 ESP32-S3 输出一段可控的超声载波”开始，到“在 Windows 宿主机上用串口网页控制，再用 Actions ATS3085S 评估板的板载 MIC 采集链路观察频率随时间变化”的完整实验。重点不是把某个低频峰值简单地命名为“超声频率”，而是把信号链每一层的物理量分开：

ESP32-S3 GPIO4 逻辑波形
        ↓
外部限流/功率驱动级
        ↓
25T 压电换能器的端电压与电流
        ↓
空气中的声压波
        ↓
Actions 芯片板载 MIC 模块与前端
        ↓
Actions 芯片音频采集/USB UAC PCM
        ↓
Windows 主机 FFT、声谱图
        ↓
我们在网页上看到的颜色和曲线

如果把最后一层的声谱图直接当成 GPIO 或换能器端的真实波形，结论很容易错位。本文会同时给出理论模型、当前测试固件的真实约束、已经观察到的现象、最可能的原因，以及下一轮实验如何把它们区分开。

:::info 先给结论

当前测试固件的默认配置是：GPIO4、25 kHz 载波、50% 载波占空、20 ms ON + 980 ms OFF，也就是 1 Hz、2% 的包络。Windows Web Serial 控制页只负责下发 ESP32-S3 的串口参数；Windows 主机分析器只接收 Actions ATS3085S 评估板通过 USB UAC 上传的 MIC PCM，再进行 FFT、声谱图和相对 dB 显示。主机分析器不是原始空气声压计，也不是换能器端电压波形查看器。

在当前会话的 16 kHz UAC PCM、最高显示约 8 kHz 的主机分析链路中，25 kHz 不能被直接显示。图中看到的 3.5 kHz 左右峰值可能来自板载 MIC/模拟前端或芯片音频链路中的非线性、方波谐波、Burst 边沿、混叠、分析窗口效应或环境声音，不能单独证明换能器端的实际载波频率。这里的“16 kHz”首先是导出给 Windows 的 PCM 流配置，不应未经固件和硬件资料确认就等同于板载 MIC 元件或 Actions 芯片内部每一级的真实采样时钟。

:::

1. 实验对象与证据边界​

1.1 当前硬件和软件链路​

本次实验使用的是 ESP32-S3 N16R8 开发板、一个标称 25T 的压电超声换能器、外部驱动/限流级，以及一块 Actions ATS3085S 评估板。硬件发布资料中的音频页把接收器标成两端模拟 MIC：ME9 的器件标识为 EM6027-32BC10&33-G，另有一个 MD7 = MIC 的替代封装位；两者通过 VMIC0 偏置和 RC 网络接入 INPUT0P/INPUT0N。PADS 发布文件给这两个位都保留了 DNP 属性，因此“原理图/器件库候选型号”和“你手上这块板实际焊接的型号”仍要用 BOM、板上丝印或实物确认。Actions 芯片的固件则把该输入选择为 AUDIO_ANALOG_MIC0，由 ADC 音频输入链路采集，再通过 USB UAC 向 Windows 提供 PCM。

本文把“固件回报的参数”视为代码事实，把“示波器测得的 GPIO 周期”视为电气事实，把“Actions 模拟 MIC 经 ADC、USB UAC 和主机分析器显示的颜色”视为经过测量链路变换后的观测事实。三者不能混为同一个量。

1.2 为什么选择 GPIO4​

测试固件没有继续使用 GPIO33–GPIO37，而是选择 GPIO4 作为通用输出。N16R8 类 ESP32-S3 模组常把一组高编号 GPIO 用于 Octal PSRAM；因此，通用测试应优先选择明确没有被板级存储器占用、并且开发板确实引出的 IO4。GPIO4 在这里的角色是“外部驱动级的逻辑输入”，不是 25T 换能器的功率输出端。

1.3 安全和边界​

裸压电片不要直接接在 ESP32-S3 GPIO4 上。GPIO 只能提供低功耗逻辑电平，压电换能器在谐振和容性负载下可能产生较大的瞬态电流或反向电压；应使用限流、匹配和必要的功率驱动级，并按换能器规格和实验台条件控制电压。

超声实验还涉及人耳不可直接感知但可能对动物、结构件、传感器和周边设备造成影响的能量。实验应在受控环境中进行，避免对无关人员、动物和他人的录音设备进行干扰，也不要把“能在某个麦克风图上看到变化”宣传成对所有录音设备都有效。

2. 从 GPIO4 输出的载波开始​

2.1 载波频率、周期和占空比​

载波是最底层的周期波形。设载波频率为 f_c，一个周期为：

T_c = 1 / f_c

当 f_c = 25 kHz 时：

T_c = 1 / 25000 = 40 μs

载波占空比 D_c 定义为一个周期内高电平时间的比例：

D_c = t_high / T_c × 100%

因此，理想的 25 kHz 逻辑方波大致如下：

       t_high                 t_low
    <---------->           <-------->
    ┌───────────┐           ┌───────────┐
    │           │           │           │
────┘           └───────────┘           └────
    <------------ T_c = 40 μs ----------->

几个具体例子：

这里的“载波占空”不是“发射 30% 的时间、停止 70% 的时间”。它只描述每一个 40 μs 周期里面高电平脉冲的宽度。

2.2 LEDC 计数分辨率与名义值​

当前固件使用 LEDC 10-bit duty resolution：

#define TEST_DUTY_RESOLUTION LEDC_TIMER_10_BIT
#define TEST_DUTY_MAX ((1U << 10) - 1U)

换算逻辑是：

duty_ticks = (1024 × duty_percent) / 100

因为固件使用整数运算，实际 tick 会有量化误差。例如：

50% → 512 / 1024 = 50.000%
49% → 501 / 1024 ≈ 48.93%
36% → 368 / 1024 ≈ 35.94%

网页显示的是用户输入的名义百分比；示波器看到的是经过 LEDC 时钟、预分频、整数 tick 量化和探头测量后的实际结果。LEDC 的频率、时钟源和占空分辨率存在硬件组合约束，不能假定任何频率都能同时得到任意高的 duty resolution。可参阅 Espressif 的 ESP32-S3 LEDC 文档。

2.3 载波占空对频谱的影响​

理想的单极性脉冲列不仅包含一个频率。设 GPIO 高电平为 V，占空为 D_c，其交流谐波幅度大致与下面的关系相关：

|A_n| ∝ |sin(π n D_c) / n|

在 50% 占空时，偶次谐波的理想分量会显著减弱；当占空偏离 50%，偶次谐波和其他脉冲形状成分会改变。载波占空从 50% 调到 30%，并不会让 25 kHz 的基波幅度按 50%/30% 线性变化。

对于单极性方波，基波幅度的一个常用比例形式是：

A1 = 2V × sin(πD_c) / π

于是：

D_c = 50%：A1 ≈ 0.637V
D_c = 30%：A1 ≈ 0.515V

两者的基波幅度差约 1.85 dB，实际还会被换能器频率响应和驱动级改变。占空为 100% 时，单极性 GPIO 会变成持续高电平，交流载波基波反而消失；因此“占空越高，超声越强”不是普遍成立的规律。

3. Burst 包络：不是另一个超声频率​

3.1 包络的定义​

Burst 是对载波进行低速门控：一段时间打开载波，另一段时间关闭载波。设：

t_on  = 包络开启时间，单位 ms
t_off = 包络关闭时间，单位 ms

那么包络周期、包络频率、包络占空分别是：

T_e = t_on + t_off                         (ms)
f_e = 1000 / T_e                            (Hz)
D_e = t_on / (t_on + t_off) × 100%         (%)

这三个量描述的是“多久发一段”和“每段发多久”，不是 25 kHz 载波本身。

3.2 当前固件的参数边界​

当前固件和网页共同使用以下边界：

最后一条意味着当前 Burst 模式的包络占空最大为 50%。例如 20/20 ms 是 50%，但 40/0 ms 的 100% 连续模式目前会被拒绝。真正支持 100% 应该在固件中增加单独的 continuous-carrier 分支，而不是让任务循环执行 vTaskDelay(0)。

3.3 常用参数的计算​

开启期间的载波周期数为：

N_on = f_c × t_on(ms) / 1000

例如 25 kHz、20 ms 开启时：

N_on = 25000 × 20 / 1000 = 500

3.4 固定周期和固定 ON 时间是两种不同实验​

如果固定 ON=20 ms，只增大 OFF，那么包络占空和包络频率会同时改变：

20/980 → 1 Hz、2%
20/80  → 10 Hz、20%
20/47  → 约 15 Hz、约 30%
20/20  → 25 Hz、50%

这适合观察“低频重复率和暗区长度如何影响声谱图”。

如果要只比较占空，而不改变包络频率，应固定总周期。例如固定 40 ms：

约 2%：1/39 ms       （受固件 1 ms 最小 ON 限制）
20%： 8/32 ms
30%： 12/28 ms
50%： 20/20 ms

3.5 载波与包络的合成表达​

可以用两个函数表达总的 GPIO 波形：

x_gpio(t) = V_gpio × e(t) × c(t)

其中：

c(t)：25 kHz 载波方波，周期 T_c，占空 D_c
e(t)：包络门控函数，每个 T_e 周期内前 t_on 为 1，其余为 0
V_gpio：ESP32-S3 GPIO 的逻辑电平，约为 3.3 V 级别

当包络处于 ON 时，LEDC 输出载波；当包络处于 OFF 时，固件把 LEDC duty 设置为 0。包络不是把载波“变成 25 Hz”，而是让 25 kHz 载波以 25 Hz、10 Hz 或 1 Hz 的节奏成组出现。

4. 从 GPIO 到 25T 换能器：中间还有一整个功率系统​

4.1 GPIO 电平不等于换能器端电压​

完整的电气链路是：

ESP32 GPIO4：3.3 V 级逻辑、小电流
        ↓
外部 MOSFET/推挽/半桥/专用驱动级
        ↓
换能器端：可能是更高的单端或差分电压
        ↓
压电片的电流、机械振动和声压

同样的 GPIO 频率和占空，在不同驱动电压、输出阻抗、串联电阻、布线和换能器安装条件下，最终声压可能完全不同。因此网页参数只描述逻辑时序，不描述声压、声功率或 dB SPL。

4.2 25T 是器件/系列标识，不是测量结果​

“25T”通常让人联想到约 25 kHz 的换能器，但实际机械谐振频率还会受到：

• 换能器本身的制造误差；
• 负载和安装结构；
• 前后腔体和反射；
• 驱动电压和波形；
• 温度、湿度和周围材料；
• 换能器的阻抗频响。

所以 25 kHz 是一个测试起点，不是仅凭型号就能证明的终点。应在换能器端使用合适的探头测电压/电流，并使用频响覆盖 25 kHz 的声学接收器测声压。

4.3 谐振和余振会改变包络的视觉效果​

压电换能器不是理想的瞬时开关。载波关闭后，机械系统可能继续振动一段时间；驱动级也可能存在储能、上升沿、下降沿和限流恢复过程。于是：

• 2% 或 20% 的 OFF 时间很长，系统有机会衰减到较低背景；
• 50% 时 OFF 只有 20 ms，余振可能还没有完全消失；
• 声谱图会显示更连续的亮线；
• Burst 边沿本身可能产生比稳定载波更宽的频谱成分。

这解释了为什么“低占空时亮暗很清楚”并不必然表示低占空时载波峰值更高，它也可能只是 ON/OFF 对比度更高。

5. Actions ATS3085S 模拟 MIC 链路究竟测到了什么​

5.1 先确定接收端的硬件身份​

这里真正有物理意义的是 Actions ATS3085S 评估板上的模拟 MIC 和芯片音频输入链路，Windows 上的页面只是最后的显示端。根据 ATS3085S/E V1.1 开发板原理图：

• ME9 的器件标识是 EM6027-32BC10&33-G，MD7 是一个通用 MIC 替代封装位；两个位在原理图网络上对应同一组 MIC 输入节点。
• PADS 发布文件把 ME9、MD7 的装配值都写成 DNP，所以资料能证明“设计候选和连接方式”，不能单独证明你手上这块板最终焊的是哪一个胶囊。需要板卡 BOM、板上丝印或实物照片来做最后确认。
• EM6027 属于两端模拟电容式麦克风，不是 PDM/I²S 数字麦克风。其一端由 VMIC0 提供偏置，声音造成的模拟电压变化经 RC 网络送到 INPUT0P/INPUT0N，再由 ATS3085S 的 AUDIO_ANALOG_MIC0 ADC 输入通道采集。器件库的 PARTTYPE 还把该 MIC 的库值写成 MAF-B6022P，但这同样不是已核对的装配 BOM 号。

如果实物确实装的是 EM6027 系列，它的资料定位是普通全向模拟电容麦克风，典型规格和频响曲线面向语音/可听声段，并不是“25 kHz 超声接收器”。因此，当前链路在 25 kHz 附近出现可见的低频结果，不能解释成 MIC 对 25 kHz 基波做了准确测量；更合理的候选包括超出额定频响后的弱响应、过载/非线性、RC/ADC 链路的混叠，以及 Burst 边沿产生的宽带成分。要证明 25 kHz 本身，仍需要频响覆盖该频段且采样率足够高的独立接收器。

因此，当前这次实验的接收链路应写成：

ESP32-S3 GPIO4 / 外部驱动 / 25T
                  ↓
              空气声压与结构耦合
                  ↓
ATS3085S 评估板模拟 MIC
（EM6027-32BC10&33-G / MIC 替代位）
                  ↓
VMIC0 偏置 + RC 网络
INPUT0P/INPUT0N 差分模拟输入
                  ↓
Actions AUDIO_ANALOG_MIC0 + ADC
采样率、增益、滤波、块缓冲
                  ↓
USB UAC PCM
当前导出：16 kHz / 16-bit / mono
                  ↓
Windows 主机分析器
波形、RMS/Peak、FFT、声谱图、相对 dB

当前工程的代码证据也对应这条链路：audio_policy_get_record_channel_id() 为 AUDIO_STREAM_MIC_IN 选择 AUDIO_ANALOG_MIC0，记录通道类型为 ADC；uac_microphone_start() 调用 audio_record_create(..., 16, 16, AUDIO_FORMAT_PCM_16_BIT, ...)，audio_record.c 再把 16 kHz 输入采样率交给 hal_ain_channel_open()。这段调用的 16 是 kHz 单位。虽然该调用处还传入了 AUDIO_MODE_STEREO，但当前 UAC 描述/README 和 Windows 端到端实测都是 16 kHz / 16-bit / mono；因此不能只看一个内部 API 参数就把最终 USB 导出通道数判断成双声道。这里的 16 kHz 是当前应用和导出 PCM 的采样配置，不等于 MIC 胶囊内部可能存在的模拟带宽、ADC 过采样时钟或芯片内部全部时序。

因此，主机分析器看到的不是 p_air(t) 的原样复制，而是一个经过模拟 MIC、Actions 芯片音频路径、USB 传输、主机缓存和分析算法之后的观测量。可以用一个更贴近当前系统的简化模型表示：

p_air(t) = H_transducer{driver[x_gpio(t)]}
y_board(t) = H_board_mic{p_air(t), position, enclosure} + n(t)
z[n] = Q_action{y_board(t), gain, filter, AGC, Fs_action, timing}
x_uac[n] = UAC{z[n], Fs_export, packet_buffer}
S(t, f) = FFT{window{x_uac[n]}}

其中 H_board_mic 表示实际装配的模拟 MIC、安装结构和前端的综合响应；Q_action 表示 Actions 芯片内部的 ADC 采样、增益、滤波、动态处理、量化和缓冲；UAC 表示以 USB 音频格式输出给 Windows 的 PCM 流。当前主机能直接分析的是 x_uac[n]，而不是 y_board(t) 或芯片内部未经后处理的模拟/ADC 样本。

这也解释了为什么观测器“不可能完全准确”：它可以在同一块板、同一固件、同一位置和同一页面配置下提供很有价值的相对比较，但它不自动等于经过声学校准的绝对测量仪器。

5.2 采样率和奈奎斯特频率​

如果导出 PCM 的采样率是 F_s，这个 PCM 序列可以直接无混叠表示的最高频率约为：

F_N = F_s / 2

当前工程配置和端到端实测给出：

PCM 采样率 Fs = 16000 Hz
采样位宽 = 16 bit
导出通道 = mono
主机 FFT 点数 N = 1024
频率 bin ≈ Fs / N = 15.625 Hz

因此，对“导出给主机的 PCM”可直接得到：

F_s ≈ N × Δf
    ≈ 1024 × 15.63
    ≈ 16000 Hz

奈奎斯特频率约为 8 kHz，所以这一路导出 PCM 的无混叠可解释频带是 0–8 kHz；这并不自动证明板载 MIC 元件、Actions 芯片内部 ADC 或模拟前端的完整频响也恰好截止在 8 kHz。

5.3 25 kHz 如何混叠成低频​

如果超出导出 PCM 奈奎斯特范围的分量在采样/降采样前没有被充分的抗混叠滤波抑制，采样后频率会按照采样率周期折叠。可以先把频率对 F_s 取模，再折叠到 0–F_s/2：

f_alias = |f - kF_s|

选择合适整数 k，让结果落在 0–F_s/2。当 F_s=16 kHz 时：

25 kHz → |25 - 2×16| kHz = 7 kHz
75 kHz → |75 - 5×16| kHz = 5 kHz
125 kHz → |125 - 8×16| kHz = 3 kHz
175 kHz → |175 - 11×16| kHz = 1 kHz

因此，若某个超出带宽的分量确实穿过了板载 MIC/Actions 音频链路的采样环节，它可能在导出 PCM 中折叠到较低频率；但一个规范的抗混叠滤波器也可能在采样前把它大幅衰减。截图里的 3563 Hz 不是“25 kHz 被直接测成 3563 Hz”，更可能是谐波、残余混叠、板载 MIC 或芯片前端的非线性产物、Burst 瞬态、实际频率偏移或环境声音的组合。

一个简单的诊断是把载波依次改成 24、25、26 kHz，并同时记录 GPIO、25T 端和主机收到的导出 PCM。若接收链路中存在可见的直接泄漏分量，16 kHz 导出采样下它大致会向 8、7、6 kHz 移动；如果 3.5 kHz 峰值几乎不动，它就不太可能是载波基波的直接混叠。但这仍不能排除 Actions 模拟 MIC/ADC 链路在采样前已经完成了非线性解调或滤波；要区分这些情况，必须检查更高带宽的电气/声学测量。

5.4 非线性为什么会产生“很多频率”​

理想线性接收链路只会保留输入中已有的频率成分。现实中的板载 MIC 模块、前端、Actions 芯片 ADC/DSP、增益或自动增益控制、保护器件，以及空气/结构耦合都可能引入非线性或动态处理，可以用多项式近似其中一部分：

y(t) = a1 x(t) + a2 x²(t) + a3 x³(t) + ...

非线性会产生：

• 载波二次、三次等谐波；
• 载波与环境声音的和频/差频；
• 载波与包络的解调分量；
• 快速 Burst 边沿造成的宽带瞬态；
• ADC 或模拟前端削顶后产生的宽频谐波。

如果输入是一个高频载波和一个低频包络的乘积，频域上会出现卷积关系。理想情况下，包络会在载波两侧形成边带；如果接收链路存在非线性，还可能把载波和包络变成可被当前低带宽 PCM 看到的低频成分：

f_c ± k f_e

但“看到很多亮色”不等于“所有频率都同样强”。真正显示出来的频谱仍受换能器频响、板载 MIC 频响、Actions 芯片增益/滤波/AGC、导出采样和混叠、窗函数、噪声底、主机分析窗口以及显示色阶影响。要判断是否真的进入非线性区，应同时检查板端 PCM 是否削顶、降低 25T 驱动后频谱是否按比例收敛、关闭或固定 AGC（若固件允许），以及改变载波后哪些峰跟着移动。

5.5 为什么这个观测器只能作为“相对观测”​

这条链路至少有四套时间和幅度尺度：

所以页面横轴的时间是“分析帧被处理或显示的时间”，不是 ESP32 GPIO 边沿的绝对时间戳；页面看到的亮暗变化与 GPIO 包络之间还可能有声传播延迟、机械余振、芯片音频缓冲和主机处理延迟。若要做严格时序对齐，应把 GPIO/25T 端示波器触发信号和 Actions 板输出的原始 PCM 同时录下，再用触发点或互相关估计延迟，而不能只凭浏览器刷新时刻对齐。

幅度也一样：页面的相对 dB 可以比较同一链路中“改变参数前后”的变化，但板载 MIC 灵敏度、安装方向、距离、外壳共振、芯片增益/AGC、量化、削顶和页面自动色阶都会改变读数。没有声压校准器、已知灵敏度和完整频响曲线，就不能把页面上的 dB 直接写成 dB SPL、瓦特或 25T 声功率。

6. FFT 和声谱图的区别​

6.1 当前 FFT 频谱​

当前 FFT 表示“Actions 板载 MIC 链路输出到主机的一小段 PCM 时间窗口”内的频率分布：

横坐标：频率
纵坐标：幅度或功率的 dB 表示
只代表当前这一小段时间

离散傅里叶变换可以写成：

X[k] = Σ x[n] w[n] exp(-j 2πkn/N)

其中 w[n] 是窗函数。当前主机分析器使用 1024 点 Hann 窗时，导出 PCM 的频率 bin 间距约为 15.63 Hz，但这不意味着实际频率测量误差必然只有 15.63 Hz；窗函数主瓣宽度、信噪比、峰值插值、Actions 芯片输出的时序稳定性和信号是否稳定都会影响读数。这个参数描述的是主机 FFT，不是板载 MIC 元件本身的“频率分辨率”。

6.2 声谱图​

声谱图是连续地对多个“已由 Actions 板载 MIC 链路输出的 PCM 时间窗口”做 FFT，再把结果排列起来：

横坐标：时间
纵坐标：频率
颜色：该时间-频率格子的能量，通常用 dB 映射

可以写成：

S(t, f) = |FFT(windowed_x_uac_at_time_t)|²

因此，声谱图里的颜色不是“占空百分比”，而是主机分析器在一个时间窗口内对导出 PCM 的某个频率带计算后再映射出来的相对能量。它已经包含了板载 MIC、Actions 芯片音频处理、USB PCM 格式、FFT 窗函数和页面色阶的影响。若网页使用当前 FFT 帧相对能量或自动色阶，不同实验之间的颜色甚至不能直接进行绝对比较。

6.3 为什么 2% 和 20% 在声谱图上特别清晰​

当前 FFT 时间窗口约为：

1024 / 16000 = 64 ms

对固定 ON=20 ms 的实验：

这不是包络失效，而是短时 FFT 的时间平均效应。要看 20 ms Burst 的边沿，应减小 FFT 点数，例如 256 点对应约 16 ms 的时间窗，但频率分辨率会降低到 62.5 Hz/bin；这是时间分辨率和频率分辨率之间的基本权衡。

6.4 亮线、竖条和宽带颜色分别意味着什么​

• 水平亮线：某个频率成分在一段时间内持续存在。
• 水平亮线亮度周期性变化：这个频率被包络调制。
• 竖向宽带亮条：Burst 开始/结束、点击、机械冲击或其他瞬态。
• 从低频到高频都一起变亮：可能是瞬态、削顶、噪声、自动增益或显示色阶，不应直接解释为“所有频率都被超声激发”。
• 固定频率线不随载波变化：更可能是环境声音、设备固定噪声或非载波相关产物。

7. 当前串口固件和网页上位机​

7.1 串口协议​

当前 ESP32-S3 固件使用 UART 8N1，默认 115200 baud。支持的命令如下：

典型状态回报如下：

freq=25000 Hz, carrier_duty=50%, burst=20ms/980ms, envelope=2%, running=yes

这里的 carrier_duty 是载波占空，envelope 是包络占空，两者必须分开理解。

7.2 网页上位机的两个本地页面​

两个页面彼此独立，可以同时打开，但 ESP32-S3 的串口不能同时被其他串口监视器占用。Web Serial 页面应使用 Windows Chrome 或 Edge 打开，浏览器串口选择框会让用户选择 ESP32-S3 对应的 COM 口。

7.3 “参数跳来跳去”的网页问题​

最初的网页每 2 秒发送一次 status，并在收到状态后把设备参数写回输入框。这样会产生一个竞态：

用户正在编辑网页参数
        ↓
自动 status 返回旧设备值
        ↓
旧值覆盖了尚未应用的新值

网页随后做了三项修正：

1. 未点击应用的输入被标记为 dirty，状态轮询只更新设备状态卡，不再覆盖输入框。
2. 串口写入使用队列，避免 status 和 freq/duty/burst 交错写入。
3. 增加“实时应用”模式，调节停止约 350 ms 后自动发送一组参数；手动模式仍需点击“应用参数”。

这解决的是网页交互和命令时序问题，不等于让声学系统变成硬实时。当前固件的载波由 LEDC 硬件产生，而 Burst 的毫秒级开关由 FreeRTOS 任务延时参与，边沿仍可能有 tick 级抖动。

8. 对已经观察到现象的完整解释​

一个特别重要的区别是：

低包络占空时“看起来更清楚” ≠ 瞬时超声峰值更大

它常常只说明 OFF 区间足够长，显示系统能把 ON 和 OFF 分开；高包络占空时，短时 FFT 和机械余振把两者平均成一条连续的亮线。

9. 可复现的验证流程​

9.1 第一步：先用串口状态确认命令真正生效​

不要只看网页输入框，要看 ESP32-S3 回报的 status：

status
freq 25000
duty 50
burst 20 980
start
status

预期回报应包含：

freq=25000 Hz, carrier_duty=50%, burst=20ms/980ms, envelope=2%, running=yes

如果 status 没变，主机分析器观测到的变化就不能归因于新参数。

9.2 第二步：示波器测 GPIO4​

在 GPIO4 或外部驱动级逻辑输入端测量：

1. 连续时间尺度下确认 ON/OFF 周期。
2. 微秒时间尺度下确认载波周期约 40 μs。
3. 测量高电平宽度，验证载波占空。
4. 不要把高压换能器端直接接普通示波器地夹；换能器端应使用合适的差分/高压探头。

示波器观测优先级高于网页状态，因为网页状态是软件设定值，示波器才是实际电气时序。

9.3 第三步：用固定 40 ms 包络比较占空​

为了比较 20%、30%、50% 而不改变 25 Hz 包络频率：

burst 8 32       → 20%
burst 12 28      → 30%
burst 20 20      → 50%

每组至少采集 5–10 秒。固定 Actions 评估板的板载 MIC 位置、驱动电压、载波频率和载波占空，不要同时改变多个变量。

9.4 第四步：正确阅读声谱图​

建议记录以下设置：

• 采样率 F_s；
• FFT 点数 N；
• Hop size/重叠率；
• Hann 等窗函数；
• dB 色阶是否固定；
• 是否启用了 AGC、自动归一化或削顶保护；
• Actions ATS3085S 板载 MIC 模块及前端的频响、增益、AGC/滤波和削顶行为；
• 主机分析器收到的是原始 PCM 还是已经经过芯片端处理的 PCM；
• 导出 PCM 的采样率 F_s，注意它不一定等于板载 MIC 元件内部的全部时序；

如果当前导出 PCM 是 16 kHz，那么 1024 点时间窗约为 64 ms，会明显模糊 20 ms 的 Burst 边沿，可以尝试 256 或 512 点；这只改变主机分析器的时间/频率折中，不会提高板载 MIC 或 Actions 音频链路的物理带宽。若要确认 25 kHz 本身，则必须用频响覆盖 25 kHz、采样率至少 96 kHz 且明确抗混叠特性的电气或声学接收链路。

9.5 第五步：用数据而不是颜色比较​

对于一个固定频带，可以计算每个短时窗口的带内能量：

P_band(t) = Σ |X_t[k]|²,  k ∈ 目标频带

然后在完整包络周期上计算：

D_measured = measured_on_time / measured_period
RMS_period = sqrt(mean(x[n]² over complete periods))

不要只比较“哪张图更黄”。色阶自动变化时，同一个绝对能量可能被绘制成不同颜色；相对 dB 图也不能直接当成校准声压图。

10. 进一步的信号解释​

10.1 为什么 Burst 会产生边带​

时域相乘对应频域卷积：

x(t) = e(t)c(t)
X(f) = E(f) * C(f)

如果 e(t) 是周期性方波包络，E(f) 在包络频率的整数倍附近有分量；与载波谱卷积后，会在载波及其谐波两侧产生：

f_c ± f_e
f_c ± 2f_e
f_c ± 3f_e
...

如果只发一个有限长度的 Burst，时间截断还会使频谱主瓣变宽，近似宽度与 1/t_on 相关。t_on=20 ms 时，宽度量级约为几十 Hz；这与 15.63 Hz/bin 的低采样 FFT 共同造成频谱扩散。

10.2 为什么低占空可能出现更宽的可见频谱​

载波稳定段主要体现换能器和接收链路的窄带响应，而 ON/OFF 边沿包含较快的时间变化。时间变化越快，频谱越宽；因此低占空、清晰分离的 Burst 可能显示明显的宽带竖条或边沿噪声。

这并不表示低占空让 25 kHz 变成了“所有频率”。更准确的说法是：包络门控把一个稳定载波变成了带有边沿和侧带的时变信号，而接收链路又可能把超出带宽的部分混叠到可见频段。

10.3 平均能量、峰值能量和感知强度不是同一个指标​

对于峰值声压在 ON 期间保持不变的理想门控信号：

峰值声压：主要由 ON 期间的载波和驱动决定
周期平均功率：大致随 D_e 变化
周期 RMS 压力：大致随 sqrt(D_e) 变化
人耳/麦克风感觉：还受频率、响度、AGC、余振和环境反射影响

所以不能从“感觉差不多”反推“包络没生效”，也不能从“声谱图颜色差不多”反推“平均声能相同”。

11. 当前实验能下什么结论，不能下什么结论​

已经可以确认的结论​

1. ESP32-S3 固件可以通过 GPIO4 产生名义 20–30 kHz 的 LEDC 载波。
2. 载波频率和载波占空与 Burst 包络是相互独立的两个层次。
3. 20/980 ms 是 1 Hz、2% 包络；20/20 ms 是 25 Hz、50% 包络。
4. 当前串口网页可以动态下发 freq、duty、burst、start 和 stop。
5. 声谱图的横轴是主机分析帧时间、纵轴是导出 PCM 的频率、颜色是该帧短时相对能量的可视化；它观察的是“ATS3085S 模拟 MIC → VMIC0/INPUT0P-N → ADC → 16 kHz PCM”链路的输出，不是空气声压原样。
6. 当前会话的 16 kHz UAC PCM/0–8 kHz 主机分析链路不能直接观察 25 kHz；这不能替代对板载 MIC、Actions 芯片内部采样和抗混叠路径的硬件/固件确认。

还不能仅凭当前页面确认的事情​

1. 25T 两端的真实电压、电流和功率。
2. 空气中的绝对声压级或声功率。
3. 25T 的实际机械谐振频率是否正好为 25 kHz。
4. 3563 Hz 峰值是否来自 25 kHz 的某个特定非线性产物。
5. 某种包络是否能对所有板载 MIC 模块、不同 Actions 固件版本、不同采样时序和所有录音设备产生同样效果。
6. 当前实验是否实现了任何广义的“录音屏蔽”。

12. 最终的工程心智模型​

可以用下面四句话记住整个系统：

载波频率决定“每秒振荡多少次”。
载波占空决定“每个载波周期内脉冲有多宽”。
包络频率决定“每秒发几段 Burst”。
包络占空决定“每个 Burst 周期有多少时间处于开启”。

再往后还有三次变换：

GPIO 逻辑时序
  → 驱动级电压/电流
  → 换能器机械振动与空气声压
  → Actions 板载 MIC/音频采集时序/增益滤波/USB PCM
  → Windows 主机采样块、FFT、声谱图和相对 dB

因此，一张低采样率、经 Actions 板载 MIC 链路得到的声谱图只是整条系统在主机端的投影。它非常适合观察“是否存在周期性声学变化、Burst 是否产生亮暗结构、某些可听频段是否出现异常成分”，但不能替代 GPIO 示波器测量，也不能替代覆盖超声频段的接收器，更不能在没有校准时把相对 dB 解释成绝对声压级。

本次实验最可靠的下一步，是把三种测量同时放在一起：

1. 示波器确认 GPIO4 和外部驱动输入的实际时序；
2. 高带宽探头或超声接收器确认 25T 端的载波和包络；
3. Windows 主机分析器观察 Actions ATS3085S 模拟 MIC/ADC 链路中的混叠、非线性和低频可见结果，并把控制参数、PCM 元数据和固件版本一起记录。

只有这三层结果彼此对应，才能把“参数设置”“电气输出”“实际声学现象”和“接收页面颜色”完整地闭合起来。

参考资料​

• Espressif ESP32-S3 LEDC Programming Guide
• ESP-IDF Programming Guide
• Actions ATS3085S/E V1.1 开发板硬件发布资料：原理图 ATS3085E_DEMO_DVB_V1.1_20230811，音频页的 MD7/ME9、VMIC0、INPUT0P/INPUT0N 网络。
• Actions ATS308X SDK：audio_policy.c 的 AUDIO_ANALOG_MIC0 ADC 通道，以及 usb_msc_uac_demo 的 16 kHz / 16-bit 采集配置。
• EM6027 系列电容麦克风数据页

很多 BLE 產品的設定檔裡都能看到一個似乎很有「規範感」的數字：MAX_BONDS = 8。接著很自然就會產生兩個誤解：Bluetooth 是否最多只能記住 8 台裝置？記住 8 台是否代表可以同時連上 8 台？

答案都是否定的。

可以先用四個生活化比喻建立直覺：

• Bond DB 是鑰匙櫃：保存曾經安全配對之裝置的長期密鑰。
• Resolving List 是門衛的快速識別名單：看到輪換地址時，Controller 可以先在門口認出對方。
• Active Connection 是通信車道：此刻真正佔用控制器、RAM 與無線時隙的連線。
• ADMIN／MEMBER 是軟體權限系統：決定一個已驗證會話能做什麼，而不是決定 Link Layer 如何加密。

比喻只負責建立直覺；下面會把每一層換回嚴謹的技術定義。

日期：2025 年 12 月 15 日 來源：Google A2UI 團隊 編譯/整理：[w0x7ce]

生成式 AI 在生成文字、圖像和程式碼方面的表現已經相當出色。而現在，Google 認為是時候讓 AI 用於生成**上下文相關的介面（Contextually Relevant Interfaces）**了。

Google A2UI 團隊近期正式公開了 A2UI 專案，旨在與開發者社群就這種早期階段的格式和實作進行協作。A2UI 的設計初衷是為了解決來自代理（Agents）的互通性、跨平台、生成式或基於模板的 UI 回應所面臨的特定挑戰。

透過 A2UI，代理可以生成最適合當前對話情境的介面，並將其發送到前端應用程式。Google 團隊表示，他們已在內部多個產品中構建並使用 A2UI，現在希望透過開源與社群互動，以完善規範、增加更多傳輸方式，並擴展更多的客戶端渲染器（Renderers）和整合支援。

A2UI 是一個開源專案，包含一種針對「可更新、由代理生成的 UI」進行優化的格式，以及一組初始渲染器。它允許代理生成或填充豐富的使用者介面，使其能在不同的主機應用程式中顯示，並由各種 UI 框架（如 Lit、Angular 或 Flutter，未來將支援更多）進行渲染。渲染器支援一組通用元件和/或客戶端宣告的自定義元件，並將這些元件組合成佈局。

值得注意的是，客戶端擁有渲染權，並可以將其無縫整合到其品牌的 UX 中。無論是協調器代理（Orchestrator agents）還是遠端 A2A 子代理，都可以生成 UI 佈局，這些佈局將作為訊息安全地傳遞，而不是作為可執行的程式碼。

以下是 A2UI 渲染卡片的範例，展示了該技術可以實現的各種 UI 組合。