Sound of silence: 數據傳輸的小眾黑科技

上周面試了一個來自俄羅斯的 android 工程師。很 geek，對 office 的 binary format（不是後來的 xml format）做過深入的逆向工程。他在 yandex 做過產品，而不是工程師 —— 拿他的原話說，就是 Yandex 對工程師要求太高，他試了三次都沒成功，只能退而求其次做產品。當然，本文想講的不是這個哥們，而是這哥們現在所在公司 AliveCor 做的一款產品。

這是一款通過監控心率而預測潛在疾病風險（比如中風）的醫療產品（Electrocardiography，EKG）。它由一個小巧的硬體（探測器）和手機上的 app 組成。大致原理是：打開手機 app，將雙手各兩個手指摁在探測器上大約 30s，探測器會將你的實時心率發送到手機端，手機 app 會根據伺服器預先生成好的機器學習的 model（就幾兆到幾十兆）來預測潛在的心臟疾病。我嘗試了一下，不出意外地，我的心臟狀態十分正常（此處應有掌聲）。

從軟體的角度看，這款產品原理上並不複雜，複雜的是樣本分析和篩選，機器學習演算法的選擇和調優，模型的構建；而 app 本身，實現上也不算困難，困難的是如何從探測器傳輸信息給手機。從圖中我們可以看到，探測器很薄很小，厚度將將蓋過一片輕薄扁平的紐扣電池，而整體大小也就比四個手指摁在桌上的範圍大一丟丟。

我第一反應是它使用了類似 electric imp 的晶元。我在很久的一篇介紹 lockitron 的文章中介紹它，官網是 electricimp.com，感興趣的自己去看看它的 tech spec。它在一塊 SD 卡大小的 PCB 上，實現了整個 WiFi 協議棧。很可惜，面試者回答「不是」。我又試探了藍牙和 ZigBee，也不是。他說使用的是他們的私有協議，直接運行在傳輸層上，無需建連，探測器單向向周圍廣播接偵聽到的心率信息，因而電池待機能達到 12 個月之久。但具體的細節他不能透露。

面試結束後，我意猶未盡，進一步探索了 AliveCor 的官網，卻並沒有得到太多有用的信息。翻看我之前撰寫的關於 electric imp 的文章，突然想到，它會不會使用類似 blinkUp 的技術？

我們知道，在 IoT 設備間不依賴已有的複雜技術短距離交換信息（比如說，配置信息）是一個難題。拿 electric imp 為例，這塊晶元為 IoT 設備提供了簡潔可靠的 WiFi 接入能力，使得設備可以接入互聯網，接受和處理來自雲端的指令，非常強大。然而，在它能夠正常工作以前，如何將要連接的 SSID 和 password 傳遞給晶元使其能夠連接要連接的 WiFi 是個大問題。IoT 設備一般都沒有鍵盤滑鼠這樣的輸入輸出系統，目前語音控制還處於早期且價格不菲，為了提供一個一次性的配置加入語音控制晶元，得不償失。所以 electric imp 開發了 blinkUp 技術，使用可見光來交換信息。其實用可見光傳遞信息的做法歷史十分悠久了 —— 古時的烽火台，如今的旗語，紅綠燈，都使用了可見光。blinkUp 技術是將數字化的信息（比如 WiFi SSID / password）encode 成手機屏幕的閃爍，electric imp 晶元接收到這個閃爍信號，decode，就得到了原始的數據。雖然看上去挺笨拙的，使用效果還不錯。

然而，在使用 AliveCor 探測器的過程中，我並沒有看見任何類似的信號傳輸機制。

如果不是光，那還有什麼途徑可以將設備上的信息廣播出去，而手機又能夠正常接收？我能想到的答案是聲音。手機上有 microphone，可以接收外界的聲音，探測器要發出聲音也並不難，有一個支持音頻編碼的晶元即可。問題是，我在使用的過程中，也沒有聽到聲音，難道是某種超聲波？

順著這個思路，我 google 了 "encode info in sound"，很快地我發現了這個產品 chirp，繼而我又發現了類似的競品：LISNR 和 google tone。

Chirp 在其 "how chirp works" 頁面中說：

There are lots of different ways to embed and extract meaning from a piece of sound. Chirp uses audio data encoding — or modulation/demodulation. Data is encoded into a series of pitches and tones on the sending device, and decoded on the receiving device.

在它進一步的介紹中也提到了 inaudible ultrasound（超聲波）。超聲波的好處是人耳聽不到，不會產生噪音，便於設備間說「悄悄話」。

回想起來，這個技術也不算新，在寬頻上網時代之前，是數據機時代。9.6k/14.4k/28.8k/56k 的「貓」，把數字信息「調製」成模擬信號，通過電話線傳輸到網路的另一端，同時把傳入的模擬信號，通過「貓」再「解調」成數字信息。而在電話線上傳遞的模擬信號，就是音波信號 —— 早期的互聯網用戶大概還記得撥號上網時那亂七八糟，令人不快的撥號音。只不過，數據機工作於互聯網，出於通用性考慮，只處理物理層和鏈路層的事情，網路層和傳輸層還是由 IP 和 TCP/UDP 來完成。而在 aliveCor 的使用場景中，類似於 chirp 的技術從物理層一直工作到傳輸層。

由於 Chirp 等產品也並未進一步透露其實現原理，我來大概猜測一下：

物理層：晶元將要發送的信號轉換成音波，向周圍廣播。在這一層需要處理信號要被轉換成 audible sound 還是 ultrasound。

鏈路層：一個 data frame 的起止需要有一定的說明，還有容錯。我們類比 ethernet：

一個 ethernet frame 有 preamble，SFD（start frame delimiter），preamble 提示接收方新的 frame 要開始了，SFD 則表示 frame 的數據正式開始。之後就是 ethernet 的 header / payload，最後是 FCS（frame check sequence），用於做 CRC 校驗。

對於 aliveCor 的應用場景，ethernet frame 里開頭的 preamble + SFD 和結尾的 FCS 都很有必要，而 header 的 src mac / dst mac / type 則視需要決定。src mac 可以是探測器自身的 serial number 或者 device id，dst mac 甚至都不需要，因為聲音只支持單向的廣播。type 可有可無，為擴展計，可保留一兩個位元組。

網路層：應用場景不需要路由轉發的支持。

傳輸層：沒有太多一對設備間多個信道傳輸的需求，所以可以直接傳輸 payload。

至於數據的加密，則完全是應用層的事情，應用層有完整的控制權。

以此類推，aliveCor 的完整解決方案可能是這樣的：

1. 探測器端集成上文所述聲音處理晶元，當手指按壓時，探測器從待機狀態恢復，開始工作 —— 將收集到的心跳信息 encode 成 ultrasound，廣播出去（信息可能簡單加密，也可能沒加密，因為這個場景還是相對私密和安全的，聲音的覆蓋範圍可能也就在幾米間）
2. 手機端的 app 必須保持打開，以便於一直偵聽並 decode microphone 傳來的信號。當檢測到一個 frame 的 preamble / SFD 後，之後 decode 出來的數據就是心跳數據，如果校驗通過，則記錄這個數據；否則跳過。aliveCor 要求手指按壓 30s，其實並不需要這麼長時間的採樣，但考慮到探測器和手機 app 並不一定同步，一開始可能丟失一些數據，中間傳輸過程中又可能遇到壞包（比如各種其他的超聲干擾，這個幾率應該很小很小），所以 app 需要收集多於實際需要的數據。
3. 當手指停止按壓後，廣播停止。探測器進入到待機狀態，節約用電。

使用聲音做短距離的信息傳輸在 IoT 領域有很多應用場景，比如：設備間初始連接，支付，身份驗證（比如驗票）等。支付，身份驗證有其他成熟的技術，但設備間初始連接的應用場景還是很廣闊的。比如 AirPlay，每次連接時輸入 code 很麻煩，如果使用聲音直接將密碼從 apple TV 傳輸給 iPhone，那用戶體驗就大大增強了。家裡來個客人，需要 guest WiFi 的密碼，兩個手機間 beep 一下，密碼就傳過去了，省得手輸。微信傳輸名片，或者公眾號登錄，與其掃描二維碼，不如直接通過聲音傳遞信息，讓機器間自動完成處理，省去了手工「掃描」的動作。而大規模的 IoT 設備間的初始配置，也可以通過聲音進行配置的分發，類似於 "gossip"，一台設備將配置「讀」給鄰近的設備，然後一路傳遞下去，直到大家都初始化成功。

以上。