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",一台設備將配置「讀」給鄰近的設備,然後一路傳遞下去,直到大家都初始化成功。

以上。


推薦閱讀:

DMA數據傳輸
可不可以用動態圖像(動態二維碼)傳輸數據,具體怎麼實現?
一台電腦要向n台電腦傳文件,假設傳輸50G給他們,n台電腦可以相互傳輸,一次只能向一台電腦傳,怎麼做?

TAG:网络传输 | 数据传输 | 黑科技 |