INGCHIPS BLE芯片如何获得最大吞吐量

概述：文章第一部分先公布结论，第二部分是1M PHY吞吐率的实测过程与理论分析，第三部分是2M PHY的实测数据，第四部分是实操部分，喜欢BLE的朋友可以按照此部分的说明自己动手进行测试。

一、结论

使用INGCHIPS SDK中测试吞吐率的例程peripheral_throughput和central_throughput，使用两个开发板进行测试。

1M phy吞吐率≥93KBps；

2M phy吞吐率≥152KBps。

二、1M PHY      

01 实测  

为了最小化包头、包尾、校验等无法避免的数据开销，每一包数据MTU设置为247。 除去3bytes的ATT Header，则实际的ATT payload为244。 在central端连接参数使用默认值的情况下：

static initiating_phy_config_t phy_configs[] =              
{              
    {              
        .phy = PHY_1M,              
        .conn_param =              
        {              
            .scan_int = 200,              
            .scan_win = 180,              
            .interval_min = 50,              
            .interval_max = 50,              
            .latency = 0,              
            .supervision_timeout = 600,              
            .min_ce_len = 90,              
            .max_ce_len = 90              
        }              
    }              
};

 

对于1M phy来说，由主设备统计的吞吐率为：687104bps。                

使用蓝盒（ellisys）抓包：

一包间隔为62.5ms(即50*1.25ms)，观察其中的数据包发现，一个间隔有23包数据发出去。 实际发出的有效数据=23x244bytes=23x244x8bits=44896bits。 吞吐率=44896/0.0625=718336bps. 比串口统计的略大，仔细观察Ellisys窗口，发现每个连接间隔发满时，都有一次retry。在连接间隔的末尾，从设备没有回复主设备连接包，主设备进行了一次重传。  

也就是一个连接间隔实际只发了22包。

吞吐率=22x244x8/0.0625=687104，与串口的统计对应上了。

想要提升吞吐率，从上面的分析可以看到，有两个可以调整的地方，一个是每次重传的那一包，一个是连接间隔中空闲的6.116ms。

6.116ms足够传2包数据（具体传送一包的时长，参照下面的理论分析部分）。

调整连接间隔

            .interval_min = 51,              
            .interval_max = 51,

可以看到，每个连接间隔变成了63.75ms，比刚才多传了一包，24包（由于依然有一个retry包，有效包23包），连接间隔中浪费的时间4.89ms，比刚才的6.116ms少，本次吞吐率理论上比上次高。

23x244x8/0.06375=704205

             

串口显示基本上两次718336，一次673440， (718336x2+673440)/3=703370，基本一致。 参数设置为

.conn_param =              
       {              
            .scan_int = 200,              
            .scan_win = 180,              
            .interval_min = 100,              
            .interval_max = 100,              
            .latency = 0,              
            .supervision_timeout = 600,              
            .min_ce_len = 200,              
            .max_ce_len = 200              
        }

 

每个连接间隔125ms，传输有效包48包。

             

48x244x8/0.125=749568bps=93696Bps≈93KBps，

此时连接间隔的空闲时间为4.447ms，

基本上已经达到极限。

  02 理论分析

BLE连接数据包分解如下：

当ATT payload设置为244，传输一包数据需额外传输的bytes数为：

1（preamble）+4（access address）+2（LL Header）+4（L2CAP Header）+3（ATT Header）+3（CRC）=17（因为不加密，所以没有MIC）。

一包总的数据长度为17+244=261bytes=261x8bits=2088bits。

对于1Mphy来说，传输1bit时间为1us，传输一包数据就需要2088us，即2.088ms。

数据传输还有另外两个无法避免的时间开销：1）传输完一个数据包后，需要另一个设备回一个空包来保持数据传输；2）数据包之间需要有一个空闲时间来让协议栈完成数据处理，这个时间即T_IFS，150us。

空包的长度为1（preamble）+4（Access Address）+2（PDU）+3（crc）=10Bytes=80bits。

也就是说传输一个空包时间为80us，加上两个T_IFS，总共380us。

也就是说，传输244Bytes数据，实际花费的总时间=2088us+380us=2468us=2.468ms. 如果可以保持不间断地发送，吞吐率=244/0.002468=98865Bytes≈98KBps。 但是实际必然无法达到这个速度，就是由于上面说的，每一个连接间隔无法全部用于发送数据，即便让连接间隔是2.468ms的整数倍，协议栈也会留出一些空隙用于内部业务处理，对于Ingchips来说，这个间隙大约在4-6ms。 因此实测的93KBps已接近理论吞吐量的极限。 根据上面的分析，合理猜测如果把连接间隔无限拉长，可以最小化每个连接间隔空隙4-6ms的影响。但实际上，协议栈总需要时间来处理自己的事务，如果把连接间隔设的过长，且全部用于发送数据，协议栈就会在一定时间停止发送，且此连接间隔剩下的时间也不再用于发送数据，因此数据速率还会下降。

三、2M PHY      

01 Ellisys 抓包 2M PHY 方法

如下图所示，勾选2M PHY

  02 实测

在连接间隔设为60，152kBps以上。

具体过程不再赘述。

四、实操      

01 环境准备

  硬件：

 INGCHIPS开发板两套，可以咨询INGCHIPS代理商购买（上面的胶棒天线需要自备）。

 Micro USB线两条。

软件：

 INGCHIPS SDK，下载最新版本。

 串口调试工具，比如SSCOM。

  02 测试过程

说明：             
             
关于INGCHIPS SDK的下载和安装、开发软件环境的配置、例程的编译和固件下载等具体问题，桃芯官网提供了丰富的由浅入深的开发资料，前期搭建环境过程中可以参照。             
             
http://www.ingchips.cn/intro/25.html              
             
https://ingchips.github.io/docs/application-notes/                          
过程中遇到问题也可以咨询桃芯科技的代理商或原厂支持。

SDK安装好后，在两块开发板分别下载SDK提供的专门用于吞吐量测试的主从例程。

连接主设备的串口，主设备上电会有打印，有相关调试指令的说明。

主设备扫描到从设备后，会自动进行连接。

之后发送测试指令（start m->s表示主设备发，从设备收），主设备的串口就会1秒钟发送一次实时吞吐率测试结果。

可以参照第二部分中，调整连接参数的配置，观察吞吐率的变化。如果有条件，也可以用Ellisys实时抓取连接过程，观察空中包的发送情况。 注意：测试时把两套开发板放在靠近的位置上，保证二者有稳定的信号连接，信号不稳或者太差会影响吞吐率，信号强度对吞吐率的影响欢迎小伙伴们自行测试。  

　　审核编辑：汤梓红