<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[R128 BLE最高吞吐量测试正确配置测试]]></title><description><![CDATA[<p dir="auto">在R128使用前我们需要了解BLE的最高吞吐量，以方便评估相关功能的开发。</p>
<p dir="auto">首先我们了解一下哪些因素会影响蓝牙的吞吐量：</p>
<p dir="auto"><strong>1、蓝牙版本与PHY：</strong> 蓝牙设备的版本和物理层（PHY）对于吞吐量有很大影响。例如，R128设备支持蓝牙5.0，而蓝牙5.0版本后支持2M PHY，使用2M PHY会获得更高的数据吞吐量。</p>
<p dir="auto"><strong>2、DLE（数据长度扩展）：</strong> 在蓝牙4.2版本之后，BLE（蓝牙低功耗）开始支持DLE（也称为长包），使用长包可以使单个BLE数据包传输的payload达到251字节。通常，此功能是默认启用的，这有助于提高数据吞吐量。</p>
<p dir="auto"><strong>3、MTU与数据发送量：</strong> 协议规定LL data PDU的Payload最大为251字节，即一次可以传输251字节的L2CAP数据。在L2CAP Data之上还有4个字节的头部，因此L2CAP的Payload为251-4=247字节，即一次可以传输247字节的ATT data。而在ATT Data之上还有3个字节的头部，所以ATT的payload为247-3=244字节，即一次可以传输244字节的应用数据。MTU（最大传输单元）通常指的是L2CAP的Payload，即ATT data，其大小为247字节。在发送数据时，应尽量减少拆包和组包的过程，以便提高吞吐量。这意味着应用在发送数据时，应尽量每次发送不超过244字节的数据。</p>
<p dir="auto"><img src="/assets/uploads/files/1696902579858-downloadfilebyurl.png" alt="downloadFileByUrl.png" class=" img-responsive img-markdown" width="1192" height="268" /></p>
<p dir="auto"><strong>4、连接间隔：</strong>  BLE技术的特点是低功耗，这主要是因为BLE的两个设备并不是传统意义上的长连接，而是间隔一段时间进行周期性交互。这个周期性的间隔称为连接间隔。连接间隔越小，单位时间内可以发送的数据包就越多。因此，为了提高吞吐量，应尽量减小连接间隔。</p>
<p dir="auto"><img src="/assets/uploads/files/1696902585164-downloadfile1byurl.png" alt="downloadFile1ByUrl.png" class=" img-responsive img-markdown" width="1211" height="460" /></p>
<p dir="auto"><strong>5、每个连接事件的最大数据包数：</strong> 在蓝牙连接过程中，每个连接事件内可以发送的数据包数量通常为7个。如果在一个连接事件内发送过多的数据包，可能会导致吞吐量下降。因此，应尽量保证在一个连接事件内发送不超过7个数据包。</p>
<p dir="auto"><strong>6、写操作：</strong> 在蓝牙通信中，write和write_without_response、indicate和notify是常见的操作方式。write操作需要对方确认，效率相对较低；而write_without_response和notify操作则不需要对方确认，效率较高。因此，为了提高吞吐量，应优先使用write_without_response和notify操作。</p>
<p dir="auto"><strong>针对以上因素，我们可以制定出一套可以满足最大吞吐需求的正确配置</strong></p>
<p dir="auto"><strong>1、使用2M PHY</strong><br />
（1）若我方作为GATTC，应该由我方发起PHY UPDATE的动作。<br />
在较新的btmanager中已经适配（在SDK V0.9版本后才有），老版本上未有。若客户不使用btmanager，需要自行检查适配。<br />
（2）若我放作为GATTS，一般支持蓝牙的5.0的手机设备默认有PHY UPDATE的动作。</p>
<p dir="auto"><strong>2、更新LL data length</strong><br />
虽然默认支持长包功能，但是为了兼容4.0和4.1版本，蓝牙controller默认还是使用27字节的包发送。<br />
需要在连接的时候主动更新LL data length为251字节。在较新的btmanager中已经适配（在SDK V0.9版本后才有）。若客户不使用btmanager，需要自行检查适配。</p>
<p dir="auto"><strong>3、MTU与数据发送量</strong><br />
L2CAP MTU 设置为247：</p>
<pre><code>-CONFIG_BT_L2CAP_RX_MTU=65
+CONFIG_BT_L2CAP_RX_MTU=247
-CONFIG_BT_L2CAP_TX_MTU=65
+CONFIG_BT_L2CAP_TX_MTU=247
</code></pre>
<p dir="auto">同时，应用或测试demo在发送数据时，应该每次最多发送244字节。</p>
<p dir="auto"><strong>4、连接间隔</strong><br />
连接间隔范围是7.5ms ~ 4s。<br />
但是并不是越小就越好</p>
<ul>
<li>
<p dir="auto">连接间隔越小，抗干扰能力就越差。</p>
</li>
<li>
<p dir="auto">若蓝牙controller在一个连接事件中能发送7个数据包，连接间隔应该设置大于12.5ms，因为这7个包已经占用了大概9.5ms了。</p>
</li>
<li>
<p dir="auto">建议连接间隔在12.5ms、13.75ms、15ms中尝试。</p>
</li>
</ul>
<p dir="auto">（1）若我方作为GATTC，可以在btmg_le_connect中指定为连接间隔即可。<br />
（2）若我放作为GATTS，对方使用的连接间隔太大，我方可以通过协议栈主动更新，相关配置</p>
<pre><code>-# 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
</code></pre>
<p dir="auto"><strong>5、增大协议栈TX和RX buff</strong><br />
增大协议栈TX buff可以让数据能快速送到蓝牙controller。</p>
<pre><code>-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
</code></pre>
<p dir="auto">增大RX buff 可以提高接收效率：<br />
设置为255是因为包含HCI的包头4个字节。</p>
<pre><code>-CONFIG_BT_RX_BUF_LEN=88
+CONFIG_BT_RX_BUF_LEN=255

-CONFIG_BT_DISCARDABLE_BUF_SIZE=88
+CONFIG_BT_DISCARDABLE_BUF_SIZE=255
</code></pre>
<p dir="auto"><strong>6、使用write_without_response和notify发送数据</strong></p>
]]></description><link>https://bbs.aw-ol.com/topic/4371/r128-ble最高吞吐量测试正确配置测试</link><generator>RSS for Node</generator><lastBuildDate>Sun, 19 Apr 2026 06:32:23 GMT</lastBuildDate><atom:link href="https://bbs.aw-ol.com/topic/4371.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 10 Oct 2023 01:55:35 GMT</pubDate><ttl>60</ttl></channel></rss>