芯耀
330
引言
通?？蛻粼谧?a class="article-link" target="_blank" href="/tag/%E4%BD%8E%E5%8A%9F%E8%80%97%E8%93%9D%E7%89%99/">低功耗藍牙模塊設(shè)計的時候，如果藍牙模塊在實際使用場景中和手持移動設(shè)備(如手機等)綁定使用的話，往往會非常注意藍牙模塊與不同品牌、不同型號的手機的兼容性測試。這些測試項目可能包括長時間連接狀態(tài)的保持，頻繁建立連接，或主動斷連后再次建立連接等場景。 本文描述的問題是客戶在其兼容性測試中發(fā)現(xiàn)的一個比較典型的問題，即當從設(shè)備在與手機端處于連接狀態(tài)下，從設(shè)備啟動連接參數(shù)更新進程后，會導(dǎo)致斷連的問題。由于是兼容性測試，測試設(shè)備，特別是作為主設(shè)備的手機來自不同的供應(yīng)商，在兼容低功耗藍牙協(xié)議的基礎(chǔ)上，某些細節(jié)部分的差異難以避免。所以，本文只論述了該客戶問題的分析過程及得出的結(jié)果，并不期望涵蓋所有類似場景下導(dǎo)致斷連的原因。
連接參數(shù)更新進程簡述
低功耗藍牙的核心規(guī)范中有規(guī)定，當主從設(shè)備建立連接后，可以通過啟動特定的進程改變當前連接的相關(guān)參數(shù)，如連接間隔(ConnInterval)，從設(shè)備延遲(SlaveLatency)和監(jiān)控超時(SupervisionTimeout)等。
低功耗藍牙的核心規(guī)范中定義了幾個不同的連接參數(shù)更新流程，有的流程主設(shè)備和從設(shè)備都可以啟動，有的流程只能由從設(shè)備或主設(shè)備啟動。為避免引入過多對本文關(guān)注話題的無用信息，我們在這里只介紹一種由從設(shè)備啟動的連接參數(shù)更新的流程。即由從設(shè)備通過調(diào)用L2CAP 層的命令的方式啟動的連接參數(shù)更新流程。
客戶可能的測試邏輯和問題現(xiàn)象描述
客戶使用智能手機和 ST 的 BlueNRG LP 作為測試的主從設(shè)備。客戶的兼容性測試中需要使用預(yù)設(shè)連接間隔和監(jiān)控超時時間。為了在測試過程中可以實時調(diào)整相關(guān)參數(shù)，需要手機端作為主設(shè)備通過私有邏輯將新的連接參數(shù)通過低功耗藍牙連接發(fā)送給從設(shè)備( BlueNRGLP ), 并由從設(shè)備啟動上述的更新流程，以完成連接參數(shù)的更新并繼續(xù)執(zhí)行后續(xù)的其他測試項。
問題分析：
根據(jù)問題復(fù)現(xiàn)時使用低功耗藍牙抓包工具所抓取的 log 數(shù)據(jù)。
小結(jié)
上述問題的根本原因是作為主設(shè)備的智能手機雖然完成了連接參數(shù)更新流程中主從設(shè)備之間的交互，但由于其在后續(xù)規(guī)劃的連接事件，規(guī)劃的射頻任務(wù)的時間點的偏差而導(dǎo)致了斷連。
導(dǎo)致低功耗藍牙斷連的可能原因有很多，上述的情況只是其中一種。本文的意圖是介紹上述問題的分析過程，讀者可以參照本文展現(xiàn)的分析方法、將其運用到類似問題的解決過程中。
通過對抓包 LOG 中的時間戳的分析，有很大機會可以幫助找到解決問題的突破口。
