>>>

android 藍芽ble app開發中 經常會遇到很多問題，這個時候就需要用到抓包軟體進行分析，單單從現象上很難鑑定是裝置韌體端的問題，還是我們自己app寫的不對的問題。這一點是做android的是比較糾結的，因為韌體端經常是和ios通訊沒毛問題，android問題偶爾，這個偶爾很經常出現。（韌體基於cc2540 2541）

這篇記錄的內容是android app開發時遇到的，但是本身的內容卻是ble協議的一些內容，ios 也是一樣的下一篇會記錄下抓包過程與分析。

1、知識儲備：

要分析ble藍芽包 需要懂一些ble藍芽協議棧的內容，和一些核心概念。

最關鍵的幾個概念

Connection Events：連線事件

這個概念比較抽象，之前看了很多解釋不明白，ti 宣講會上講ppt講的很清楚

簡單的說就是通訊建立在連線事件上，每次連線事件時才是真正的通訊事件，其餘時間時休眠的（低功耗）

對應在程式上就是如果連線間隔的時間設定的大於 通訊間隔，就會出現資料通訊不流暢，沒有接收到週期性資料，資料一卡頓一卡頓時而沒有時而很多

Supervision Timeout：超時時間（在這個時間內沒有接收到響應就會斷開）

Slave Latency：這個不好翻譯，看圖最實在了

理解成可以忽略的空白響應數吧

Connection Interval：連線間隔

另外還有：Advertisement InterVals 廣播間隔，和名字一個意思

ConnectionParameter Update Request

有閱讀藍芽協議棧和一些材料，簡單的說就是主機決定連線引數的值( connection interval, slave latency, timeout)，從機可以請求更新這些引數，主機決定是不是接受，接受的值是多少。所以是會出現手機接受引數後和從機請求的引數有偏差，或者甚至是拒絕（ios）。

這裡不得不提到：android 和 ios 的ble開發與相容不是一個等級。

相同點：android 和 ios 都是在手機和裝置建立連線時就會預設設定這些引數，app開發是無法修改這些引數的，這些預設引數由手機廠商決定。

不同點：當產品基於功耗等的考慮是應該要修改這些引數的，都是由從機提出更新申請，ios 有保護機制當從機給的引數超過它的範圍它會拒絕這些不合理引數，然後使用預設值。而android 目前（4.3 4.4）是都會接受從機的更新引數，即使不合理。這裡就會照成一種 裝置通訊 ios可以 android出問題 而且android即使接受引數並且使用這些引數更新後還會出現和引數不和的現象，典型的就在這個timeOut上，是會比更新請求裡的timeOut長而且不同手機長的時間不一樣。ios 好像是長5秒

ios 的引數範圍還是很有參考價值的，不然在這個範圍外，ios拒絕了 ，android接受了問題就蛋疼了。

Ti 問題網站上是這麼回覆的ios ble引數範圍：http://www.deyisupport.com/question_answer/wireless_connectivity/bluetooth/default.aspx這上面找具體哪個帖子沒記錄

The connection parameter request may be rejected if it does not comply with all of these rules:

Interval Max * (Slave Latency + 1) ≤ 2 seconds

Interval Min ≥ 20 ms

Interval Min + 20 ms ≤ Interval Max

Slave Latency ≤ 4

connSupervisionTimeout ≤ 6 seconds

Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout

3、android連線引數的補充

ble 協議裡主機是對連線引數的絕對設定權，從機只能提出更新請求是否被接受是主機決定。

手機app開發裡是不存在修改這個值的api的，至少4.3 4.4 沒見到，5.0不知道。BlueDroid的android ble棧原始碼是驅動級的，即使改了，也沒用，要重新改手機的驅動檔案，我是這麼理解的，也不知道對不對

另外在做android ble OAD 線上更新韌體時，閱讀TI的sensorTag 的原始碼時發現它裡面有個 CC_SERVICE_UUID 服務可以設定OAD連線引數。而這個連線引數修改了也就修改了我們的韌體的連線引數。參看ti 的回答：

The connection control service is a separate service, and can be added by adding ccservice.c/h from Profiles/SensorProfile/. Have a look in the SensorTag project to see how it's added to the GATT server and otherwise used.

ti 的demo裡有這個cc服務的新增方法，雖然和他們的回答方法不大一樣，新增後確實能實現app更改更新引數的目的。

cc服務的流程也比較清晰，android主機告訴ble韌體我要更新引數引數是什麼什麼，然後韌體拿著這個引數來進行更新參請求，adnroid裝置再把這個請求設成此次通訊的連線引數。這個和前面所描述的android手機app開發沒有主動設定連線引數的api沒有矛盾，它是通過高數ble從機，從機提出更新，再完成更新確認

轉載於:https://my.oschina.net/dccjll/blog/1532415