在R128使用前我們需要了解BLE的最高吞吐量，以方便評(píng)估相關(guān)功能的開(kāi)發(fā)。

首先我們了解一下哪些因素會(huì)影響藍(lán)牙的吞吐量：

1、藍(lán)牙版本與PHY： 藍(lán)牙設(shè)備的版本和物理層（PHY）對(duì)于吞吐量有很大影響。例如，R128設(shè)備支持藍(lán)牙5.0，而藍(lán)牙5.0版本后支持2M PHY，使用2M PHY會(huì)獲得更高的數(shù)據(jù)吞吐量。

2、DLE（數(shù)據(jù)長(zhǎng)度擴(kuò)展）： 在藍(lán)牙4.2版本之后，BLE（藍(lán)牙低功耗）開(kāi)始支持DLE（也稱為長(zhǎng)包），使用長(zhǎng)包可以使單個(gè)BLE數(shù)據(jù)包傳輸?shù)膒ayload達(dá)到251字節(jié)。通常，此功能是默認(rèn)啟用的，這有助于提高數(shù)據(jù)吞吐量。

3、MTU與數(shù)據(jù)發(fā)送量： 協(xié)議規(guī)定LL data PDU的Payload最大為251字節(jié)，即一次可以傳輸251字節(jié)的L2CAP數(shù)據(jù)。在L2CAP Data之上還有4個(gè)字節(jié)的頭部，因此L2CAP的Payload為251-4=247字節(jié)，即一次可以傳輸247字節(jié)的ATT data。而在ATT Data之上還有3個(gè)字節(jié)的頭部，所以ATT的payload為247-3=244字節(jié)，即一次可以傳輸244字節(jié)的應(yīng)用數(shù)據(jù)。MTU（最大傳輸單元）通常指的是L2CAP的Payload，即ATT data，其大小為247字節(jié)。在發(fā)送數(shù)據(jù)時(shí)，應(yīng)盡量減少拆包和組包的過(guò)程，以便提高吞吐量。這意味著應(yīng)用在發(fā)送數(shù)據(jù)時(shí)，應(yīng)盡量每次發(fā)送不超過(guò)244字節(jié)的數(shù)據(jù)。

4、連接間隔： BLE技術(shù)的特點(diǎn)是低功耗，這主要是因?yàn)锽LE的兩個(gè)設(shè)備并不是傳統(tǒng)意義上的長(zhǎng)連接，而是間隔一段時(shí)間進(jìn)行周期性交互。這個(gè)周期性的間隔稱為連接間隔。連接間隔越小，單位時(shí)間內(nèi)可以發(fā)送的數(shù)據(jù)包就越多。因此，為了提高吞吐量，應(yīng)盡量減小連接間隔。

5、每個(gè)連接事件的最大數(shù)據(jù)包數(shù)： 在藍(lán)牙連接過(guò)程中，每個(gè)連接事件內(nèi)可以發(fā)送的數(shù)據(jù)包數(shù)量通常為7個(gè)。如果在一個(gè)連接事件內(nèi)發(fā)送過(guò)多的數(shù)據(jù)包，可能會(huì)導(dǎo)致吞吐量下降。因此，應(yīng)盡量保證在一個(gè)連接事件內(nèi)發(fā)送不超過(guò)7個(gè)數(shù)據(jù)包。

6、寫操作： 在藍(lán)牙通信中，write和write_without_response、indicate和notify是常見(jiàn)的操作方式。write操作需要對(duì)方確認(rèn)，效率相對(duì)較低；而write_without_response和notify操作則不需要對(duì)方確認(rèn)，效率較高。因此，為了提高吞吐量，應(yīng)優(yōu)先使用write_without_response和notify操作。

針對(duì)以上因素，我們可以制定出一套可以滿足最大吞吐需求的正確配置

1、使用2M PHY
（1）若我方作為GATTC，應(yīng)該由我方發(fā)起PHY UPDATE的動(dòng)作。
在較新的btmanager中已經(jīng)適配（在SDK V0.9版本后才有），老版本上未有。若客戶不使用btmanager，需要自行檢查適配。
（2）若我放作為GATTS，一般支持藍(lán)牙的5.0的手機(jī)設(shè)備默認(rèn)有PHY UPDATE的動(dòng)作。

2、更新LL data length
雖然默認(rèn)支持長(zhǎng)包功能，但是為了兼容4.0和4.1版本，藍(lán)牙controller默認(rèn)還是使用27字節(jié)的包發(fā)送。

需要在連接的時(shí)候主動(dòng)更新LL data length為251字節(jié)。在較新的btmanager中已經(jīng)適配（在SDK V0.9版本后才有）。若客戶不使用btmanager，需要自行檢查適配。

3、MTU與數(shù)據(jù)發(fā)送量
L2CAP MTU 設(shè)置為247：

-CONFIG_BT_L2CAP_RX_MTU=65
+CONFIG_BT_L2CAP_RX_MTU=247
-CONFIG_BT_L2CAP_TX_MTU=65
+CONFIG_BT_L2CAP_TX_MTU=247

同時(shí)，應(yīng)用或測(cè)試demo在發(fā)送數(shù)據(jù)時(shí)，應(yīng)該每次最多發(fā)送244字節(jié)。

4、連接間隔
連接間隔范圍是7.5ms ~ 4s。
但是并不是越小就越好

• 連接間隔越小，抗干擾能力就越差。
• 若藍(lán)牙controller在一個(gè)連接事件中能發(fā)送7個(gè)數(shù)據(jù)包，連接間隔應(yīng)該設(shè)置大于12.5ms，因?yàn)檫@7個(gè)包已經(jīng)占用了大概9.5ms了。
• 建議連接間隔在12.5ms、13.75ms、15ms中嘗試。

（1）若我方作為GATTC，可以在btmg_le_connect中指定為連接間隔即可。
（2）若我放作為GATTS，對(duì)方使用的連接間隔太大，我方可以通過(guò)協(xié)議棧主動(dòng)更新，相關(guān)配置

-# CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS is not set
+CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=y
+CONFIG_BT_PERIPHERAL_PREF_MIN_INT=11
+CONFIG_BT_PERIPHERAL_PREF_MAX_INT=11
+CONFIG_BT_PERIPHERAL_PREF_SLAVE_LATENCY=0
+CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=42

5、增大協(xié)議棧TX和RX buff
增大協(xié)議棧TX buff可以讓數(shù)據(jù)能快速送到藍(lán)牙controller。

-CONFIG_BT_CONN_TX_MAX=3
+CONFIG_BT_CONN_TX_MAX=8

-CONFIG_BT_L2CAP_TX_BUF_COUNT=3
+CONFIG_BT_L2CAP_TX_BUF_COUNT=8

增大RX buff 可以提高接收效率：
設(shè)置為255是因?yàn)榘琀CI的包頭4個(gè)字節(jié)。

-CONFIG_BT_RX_BUF_LEN=88
+CONFIG_BT_RX_BUF_LEN=255

-CONFIG_BT_DISCARDABLE_BUF_SIZE=88
+CONFIG_BT_DISCARDABLE_BUF_SIZE=255

6、使用write_without_response和notify發(fā)送數(shù)據(jù)