BLE(Bluetooh Low Energy)藍牙低能耗本身是為了盡可能的節省電池電量，因此采樣間歇式的收發機制，每次傳輸的資料量非常小，對于ATT來說，典型的是20位元組，雖然后續版本的資料量有所增加，但設備廠商有不同的實作方式，設備具體支持多長的資料發送，還是需要應用層做兼容適配，這無疑增加了開發的作業量，本文主要探討的是如何提高BLE 4.0版本下的資料傳輸率，
通常情況下，BLE傳輸資料量非常小， 有時候幾百毫秒、甚至幾秒十幾秒才會發送一次用戶資料，例如實時溫度監控，智能穿戴設備的心率，計步上傳等，有時候有需要實時大量的傳送，例如設備韌體的空中升級（OTA）、實時心電圖，脈搏圖等， 這就要求BLE設備提供在不同的應用場景下使用不同速率模式的能力，幸運的是，BLE早已考慮了這一點，規范里面提供了完善的機制來動態調整BLE主從設備的速率模式，其中一下幾個引數最為重要，稱為連接引數(connection params)
Interval Min
Interval Max
Latency
Timeout
下面以ble sniffer工具監聽到的主從設備間更新連接引數的實際互動來說明這個程序，
以從機(穿戴設備)為準，在需要傳輸大量資料的時候，可以向主機發起調節連接引數的請求包，請求包中攜帶從機想要的連接引數資訊：
這是一個L2CAP的資料包，方向為S->M表示從機發送到主機，SIG_Connection_Param_Update_Req欄位中可以看到，從機想要的連接引數范圍是
IntervalMin=0x10 -->16x1.25ms=20ms
IntervalMax=0x14 -->20=20x1.25ms=25ms
slavelatency=0
timeoutmultiplier=0x14 -->20=20x10ms=200ms
接著主機收到從機的請求引數后，會根據自己的實際能力，決定是否同意從機的要求，若同意則主機會在從機給出的引數范圍內選擇一個適合自己的引數，同時發起更新連接引數：
可以看到，這個資料包是LL層的，主機已同意了更新，并設定
interval=0x18 --> 24x1.25=30ms
latency=0
timeout=0x14 --> 20*10ms=200ms
之后主機還在L2CAP層針對從機的SIG_Connection_Param_Update_Req更新請求做了一個回應，表明主機是否同意從機請求：
這里可以看到SIG_connection_Param_Update_Rsp欄位result為0，為成功，
除了可以通過減少連接事件的間隔來提高速率之外，還有另外一種方式， 我們知道BLE的 characteristic有兩種寫入方式: writeWithResponse和writeWithoutResponse，顧名思義，一種是寫入資料到從機需要等待從機回應后才可以進行下一次發送，一種則不需要，
writeWithResponse需要回應的寫入：
writeWithoutResponse無需回應的寫：
對比兩種方式的協議決議可以看到，writeWithResponse方式在從機發送ATT_Write_Req后必須等待從機ATT_Write_Rsp回應時才能發送下一個資料包，這中間間隔了3個資料包(包含ATT_Write_Rsp)，而writeWithoutResponse使用ATT_Write_Command，無需等待回應，可以持續發送，兩次發送之間僅間隔了一個資料包，這無疑會提高了傳輸的速率，
本文談了兩種提高BLE發送資料的方式，通過實際抓包展示了這兩種方式的實際資料互動流程，需要說明的時，主機端應用層writeWithoutResponse方式持續發送，可能會把主機的發送佇列填滿，從而導致應用層的資料沒有完整的投遞到發送佇列，造成丟包，實際開發中ios系統就發現，連續寫入超過64幀(每幀20位元組)資料后，后續的資料幀就會丟失，可以推測ios的ble發送佇列大小應該是1KB，因此主機端需要一定的機制來解決這個問題，另外，發送和接收端的上層應用層需要根據業務邏輯，對ble協議堆疊提交上來的資料做一定的完整性校驗，
以上為實際開發程序中的一點體會和記錄，雖然部分術語可能表述不正確，但希望對大家有點參考啟示作用，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/174305.html
標籤：其他
上一篇：電氣完整性