<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計應(yīng)用 > 實戰(zhàn)經(jīng)驗 | 關(guān)于連接參數(shù)更新進程后導(dǎo)致斷連的問題分析

          實戰(zhàn)經(jīng)驗 | 關(guān)于連接參數(shù)更新進程后導(dǎo)致斷連的問題分析

          作者: 時間:2024-04-18 來源:STM32單片機 收藏

          01 引言

          本文引用地址:http://www.ex-cimer.com/article/202404/457777.htm

          通??蛻粼谧?a class="contentlabel" href="http://www.ex-cimer.com/news/listbylabel/label/低功耗藍牙">低功耗藍牙的時候,如果藍牙模塊在實際使用場景中和手持移動設(shè)備(如手機等)綁定使用的話,往往會非常注意藍牙模塊與不同品牌、不同型號的手機的兼容性測試。這些測試項目可能包括長時間連接狀態(tài)的保持,頻繁建立連接,或主動斷連后再次建立連接等場景。本文描述的問題是客戶在其兼容性測試中發(fā)現(xiàn)的一個比較典型的問題,即當(dāng)從設(shè)備在與手機端處于連接狀態(tài)下,從設(shè)備啟動更新進程后,會導(dǎo)致斷連的問題。由于是兼容性測試,測試設(shè)備,特別是作為主設(shè)備的手機來自不同的供應(yīng)商,在兼容協(xié)議的基礎(chǔ)上,某些細節(jié)部分的差異難以避免。所以,本文只論述了該客戶問題的分析過程及得出的結(jié)果,并不期望涵蓋所有類似場景下導(dǎo)致斷連的原因。

          02 更新進程簡述

          的核心規(guī)范中有規(guī)定,當(dāng)主從設(shè)備建立連接后,可以通過啟動特定的進程改變當(dāng)前連接的相關(guān)參數(shù),如連接間隔(ConnInterval),從設(shè)備延遲(SlaveLatency)和監(jiān)控超時(SupervisionTimeout)等。 

          低功耗藍牙的核心規(guī)范中定義了幾個不同的更新流程,有的流程主設(shè)備和從設(shè)備都可以啟動,有的流程只能由從設(shè)備或主設(shè)備啟動。為避免引入過多對本文關(guān)注話題的無用信息,我們在這里只介紹一種由從設(shè)備啟動的連接參數(shù)更新的流程。即由從設(shè)備通過調(diào)用L2CAP 層的命令的方式啟動的連接參數(shù)更新流程。 

          流程圖如圖 1 所示。流程圖的前提條件是主從設(shè)備端之間已建立連接,從設(shè)備希望改變當(dāng)前已建立連接的連接參數(shù)。 

          整個流程的步驟解析如下: 

          第一步:從設(shè)備發(fā)起 Connection Parameter Update Request,提交新的連接參數(shù)給主設(shè)備,希望主設(shè)備可以采用這些參數(shù)。主設(shè)備接收到從設(shè)備的 Request 后,會根據(jù)自身當(dāng)前條件(是否能支持這些連接參數(shù))決定是否接受請求。如果接受,則執(zhí)行第二步;如不接受,則直接跳到第四步拒絕該 Request。 

          第二步:主設(shè)備接受請求,給從設(shè)備發(fā)送鏈路層數(shù)據(jù)包LL_CONNECTION_UPDATE_REQ,該數(shù)據(jù)包中包含了主設(shè)備在分析了從設(shè)備在第一步中提交連接參數(shù)后,決定最終使用的目標(biāo)連接參數(shù),并約定在后續(xù)的特定連接事件開始使用新的連接參數(shù)。 

          第三步:從設(shè)備在接收到 LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包后發(fā)送一個鏈路層的空包作為響應(yīng),并結(jié)束當(dāng)前連接事件。 

          第四步:主設(shè)備發(fā)送 L2CAP 層的 Connection Parameter Update Response 命令,作為對第一步中 Request 命令的回復(fù),回復(fù)中的相關(guān)標(biāo)志標(biāo)明是接受(Accept)還是拒絕(Reject)之前的 Request 命令。如果是接受,則主從設(shè)備雙方會在第二步中LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包中所指定的后續(xù)特定連接事件中開始使用新的連接參數(shù),并成功完成連接參數(shù)更新過程。

          圖片.png

          圖1.連接參數(shù)更新流程

          03 客戶可能的測試邏輯和問題現(xiàn)象描述

          客戶使用智能手機和 ST 的 BlueNRG LP 作為測試的主從設(shè)備??蛻舻募嫒菪詼y試中需要使用預(yù)設(shè)連接間隔和監(jiān)控超時時間。為了在測試過程中可以實時調(diào)整相關(guān)參數(shù),需要手機端作為主設(shè)備通過私有邏輯將新的連接參數(shù)通過低功耗藍牙連接發(fā)送給從設(shè)備( BlueNRGLP ), 并由從設(shè)備啟動上述的更新流程,以完成連接參數(shù)的更新并繼續(xù)執(zhí)行后續(xù)的其他測試項。 

          問題現(xiàn)象: 

          主從設(shè)備在完成上述流程第四步后,且主設(shè)備發(fā)送 Connection Parameter UpdateResponse 命令所給出的響應(yīng)也是接受的情況下,主從設(shè)備在上述流程中第二步LL_CONNECTION_UPDATE_REQ 命令所指定的特定連接事件中開始采用新的連接參數(shù)時會發(fā)生斷連。從設(shè)備重新進入廣播狀態(tài)。 

          客戶的疑惑點在于主從設(shè)備已經(jīng)完成了上述連接參數(shù)更新的交互,意味著應(yīng)該可以順利切換到新的連接參數(shù),沒有道理會導(dǎo)致后續(xù)的斷連,由于作為主設(shè)備的智能手機是某大品牌產(chǎn)品,懷疑 BlueNRG 的協(xié)議棧是否存在兼容性問題。

          04 問題分析

          根據(jù)問題復(fù)現(xiàn)時使用低功耗藍牙抓包工具所抓取的 log 數(shù)據(jù),做如下分析。

          4.1.分析 LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包內(nèi)容

          4.1.1. 如圖 2 所示,LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包內(nèi)容,需要重點關(guān)注如下數(shù)據(jù):

          1. Event counter:29, 表示 LL_CONNECTION_UPDATE_REQ 發(fā)送時所在的連接事件編號為 29。

          2. Instant:35:約定在第 35 個連接事件中,主從設(shè)備開始使用新的連接參數(shù)。

          3. Interval:816(1020msec), 表示新的連接間隔為 1.02 秒。

          4. Window Size/Window Offset:第 35 個連接事件中,主從設(shè)備開始使用新的連接參數(shù)進行第一次數(shù)據(jù)包交互時,接收、發(fā)送窗口的定時信息。

          圖片.png

          圖2.LL_CONNECTION_UPDATE_REQ PDU 抓包數(shù)據(jù)

          4.1.2. 從下圖 3 中獲取從連接事件 29 到從設(shè)備進入廣播狀態(tài)這個過程中每個連接事件及連接時間中數(shù)據(jù)包收發(fā)的時間戳。

          圖片.png

          圖3.時間戳

          從圖 3 中可以看出:

          1.從連接事件 29 到連接事件 34,連接間隔為 30ms,即舊的連接間隔。

          2. 連接事件 35 中主設(shè)備的發(fā)包時間和連接事件 34 的開始時間差大大超過 30ms,所以可以再次確認(rèn)是在連接事件 35,主從設(shè)備開始使用新的連接參數(shù)。

          3. 從連接事件 35 開始及后續(xù)的 3 個連接事件中,只有主設(shè)備發(fā)送空包,從設(shè)備沒有發(fā)送空包。

          4. 由于新的連接參數(shù)的監(jiān)控超時時間在客戶的測試中為 4 秒,所以從設(shè)備沒有發(fā)送空包的 4 個連接事件結(jié)束后,即發(fā)送了斷連。然后,從設(shè)備重新開始發(fā)送廣播包。

          4.1.3. 如下圖 4,通過分析抓包 LOG 中各個連接事件、即數(shù)據(jù)包發(fā)送的時間戳后發(fā)現(xiàn):

          1.通過 LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包中 transmitWindowOffset 計算出TransmitWindow 的開始時間點應(yīng)該在 11.477925s

          2. 從抓包的 log 信息中發(fā)現(xiàn),主設(shè)備實際的發(fā)包時間點在 11.477909s,也就是主設(shè)備的發(fā)包時間先于藍牙協(xié)議中規(guī)定的 TransmitWindow 的起始點,導(dǎo)致從設(shè)備無法接收到來自主設(shè)備的空包,從而無法在同一連接事件(連接事件 35 及后續(xù)的 3 個連接事件)中反饋一個空包,進而導(dǎo)致 4 秒監(jiān)控超時,最終導(dǎo)致斷連。從設(shè)備退出連接態(tài)后重新進入廣播態(tài)。

          圖片.png

          圖4.連接事件即數(shù)據(jù)包發(fā)送時間分析

          05 小結(jié)

          上述問題的根本原因是作為主設(shè)備的智能手機雖然完成了連接參數(shù)更新流程中主從設(shè)備之間的交互,但由于其在后續(xù)規(guī)劃的連接事件,規(guī)劃的射頻任務(wù)的時間點的偏差而導(dǎo)致了斷連。

          導(dǎo)致低功耗藍牙斷連的可能原因有很多,上述的情況只是其中一種。本文的意圖是介紹上述問題的分析過程,讀者可以參照本文展現(xiàn)的分析方法、將其運用到類似問題的解決過程中。

          通過對抓包 LOG 中的時間戳的分析,有很大機會可以幫助找到解決問題的突破口。



          評論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();