目前BLE已经发布到BLE5.2的标准，而蓝牙的传输速率，在BLE4.2和BLE5.0版本上分别进行了提升，这里介绍下使用Noridc芯片时，如何进行配置，以达到最快的传输速度（只讨论1主对1从的情况）。

这里对一些后面用到的名词做一下简单介绍，如果要详细了解，可以自行进行查找。

在BLE中，作为Client端，可以通过write command和write request方式进行发送数据，参考蓝牙规范Vol3.Part F.3.4.5章节。 write command ： client向server发送命令，不需要server给应答。 write request ： clien向server发送请求，需要server给出ack。

作为server端，可以通过Notification和indication方式发送数据给client端，参考蓝牙规范Vol3.Part F.3.4.7章节。 Notification：server向client发送通知，不需要client应答。 Indication : server向client发送通知，需要client应答。

ATT_MTU : MAXIMUM TRANSMISSION UNIT,即在一个传输单元中的最大有效数据传输量，mtu的格式为1字节op_code，2字节attr handle，因此实际一帧传输的用户数据为ATT_MTU-3。在BLE4.0中,只支持23的ATT_MTU，在BLE4.2以后，ATT_MTU最大可以是247字节。

DLE: dat length extension,一般建议设置为ATT_MTU+4，如果低于ATT_MTU，ATT data会被分包，这里记得就行，后面会单独开一个章节介绍一下。

CLE ：connection event length extension，链接事件长度扩展，在BLE4.0中，单个连接间隔，最多只能发送4（IOS）或者6（Android）个数据包，当打开CLE功能时，协议栈会判断链接间隔剩下的时间是否还支持发送数据包，如果还有时间，那么会继续进行数据发送，而不是受限于6个包。

connection interval ：链接间隔，主从机建立连接以后，每隔多久交互一次数据，IOS要求连接间隔最小时15ms,最大最小之间的时间差值最低15ms，因此IOS支持的最快连接间隔最小最大分别是15ms-30ms，安卓端最低7.5ms。

Nordic官方公布的协议栈理论速度如下，这里只讨论最快速度，所以只看没有ack的Notification和Indication方式参考协议栈手册BLE data throughput章节：

nRF51不支持ATT_MTU扩展,也不支持DLE，CLE和LE 2M PHY，因此，使用最快的7.5ms的连接间隔，23字节的ATT_MTU，BW Config配置为HIGH时，Notification和write command方式速率为149.2kbps，Indication和write request方式速率为10.6kbps。

nRF52系列支持上面所有的特性。 在ATT_MTU=23，其他特性都不打开的情况下，也就是BLE4.0的标准特性下，传输速率如下图所示：

对比上面的51系列，可以看到，同样的LE 1M PHY条件下，52的速率为192kbps，速度提高了53kbps左右，而LE 2M PHY情况下，速率为256kbps。

在ATT_MTU=158，其他特性都不打开的情况下，传输速率如下图所示：

可以看到，在2M PHY的情况下，速率为330kbps。

在ATT_MTU = 247,DLE=251,CLE = conn interval情况下，传输速率如下：

在打开CLE的情况下，传输速率最快达到1376kbps，这个就是目前我们所能达到的最快的速率。

可以看到，影响蓝牙传输速率的因素有：

以下代码测试均以Nordic SDK中的ble_app_uart为基础，手机端使用安卓一加6进行测试，手机支持上面提到的所有特性。：

目前nordic支持51的最后一个版本sdk为SDK12.3，以该版本sdk为例进行测试，开发环境为keil。 由于nRF51在传输速率方面只支持BLE4.0，所以我们需要配置的参数只有连接间隔和BW Config选项。

对于链接间隔，理论上是越小越好，但是IOS要求最低是15ms-30ms，因此，使用这个范围，可以达到最快的传输速度，但是考虑到手机兼容性，可以适当的将这个最大值调高一点。

还有就是协议栈初始化时，配置BW Config为high。

role的角色定义如下，根据自己需要配置。

51的配置部分比较少，需要注意的是，在发送数据的时候，只要api的返回值不是 NRF_ERROR_RESOURCES或者在更早的sdk中，应该是NRF_ERROR_NO_TX_BUFFER，就连续调用发送的api进行发送数据。 如果发生了上面的error，那么就等触发一个tx_complete事件，再继续发送。

github测试demo：https://github.com/faithlm/ble_app_uart_throughout_test

目前最新版本SDK为sdk17.02，以该版本sdk进行测试，以该版本sdk为例进行测试,开发环境为ses。 从上面协议栈参数配置可知，如果要达到最快的速率，需要配置如下参数:

目前协议栈支持的最大 att_mtu 为247，如果要修改，可以更改sdk_config中的如下选项：

目前版本协议栈支持最大的DLE为 251，可以通过sdk_config.h 的如下选项进行配置：

连接事件长度扩展，可以通过下面接口进行配置，配置放在协议栈初始化后面：

这里还有一个参数需要注意，NRF_SDH_BLE_GAP_EVENT_LENGTH，这个定义了连接事件的长度，单位是1.25ms，在sdk_config.h中配置，一般情况下，这个值可以等于连接间隔：

目前支持3中LE PHY，分别是LE 1M PHY，LE 2M PHY，LE CODED PHY，其中LE 2M PHY用于高速率,，而理论距离是LE 1M PHY的一半，而LE CODED PHY用于长距离模式，LE 1M PHY兼顾了距离和速率，可以根据自己实际需要进行选择，如果对传输距离有要求，需要谨慎选择。 LE PHY 可以通过调用sd_ble_gap_phy_update(uint16_t conn_handle, ble_gap_phys_t const *p_gap_phys)接口发起更新，一般在peripheral端，收到ble_evt_connected事件的时候进行请求更新。如下所示，即可配置为只支持2M 的PHY：

由于启用了CLE功能，所以这里不需要根据nRF51的方式，使用最小的连接间隔，调整一个比较大的就可以,注意，需要保持NRF_SDH_BLE_GAP_EVENT_LENGTH大于等于连接间隔，协议栈给出的参考值是50ms或者400ms，对应的速率分别是1328kbps和1376kbps。

在ram空间有剩余的情况下，可以给协议栈配置更大的queue大小，增大缓存，默认值是1，根据实际情况配置。 下面的给协议栈配置了长度为7的队列缓冲区。

注意，经过上面的修改以后，在协议栈初始化时，会报NO_MEM的错误，，如下图所示，这个时候log会提示需要将ram修改为多大，根据需要进行调整即可：

经过上面修改，即可达到最大的传输速率，理论值是1376.2 kbps

github上的demo，增加了数据发送及时间记录，可以进行验证，测试结果如下图，8s时间，发送1220*1000 Byte数据，相当于传输速率为1220kbps，已经接近理论极限值。