蓝牙协议栈时隙分析

1 需求

使用手上现有的JL开发板测试，通过射频电路开启后会额外消耗10-20mA的电流来反推实际射频电路的工作状态；

通过射频电路的工作状态来反推射频电路的时隙分布，快速验证 需求可行性；

2 BR 蓝牙

2.1 未连接

EDR约200ms左右进行一次inquery scan，当接收到手机的inquery请求之后，EDR就会立即进入page scan数据交互；

可知EDR的接收射频开启的电流约20mA；

2.2 连接未播放音乐，未通话；

EDR蓝牙以625us作为一个数据slot周期，一个tx+rx为1.25ms；每10ms有8次交互；

rx射频电路每次都开启，接收应答包；后续开sniff优化后可仅在约定的rx响应即可；约20ms tx开启回复一次数据；

可知EDR的发送射频开启的电流为40mA；

2.3 连接播放音乐

箭头部分为rx接包，黄色框出为tx slot 回复包；

图2可知rx单包约3.75ms，6slot，acl包为"2-DH5"，单包可解压14.5ms的音频；

图1时间轴共160ms，11包acl包可解压159.5ms音频；单秒68包约986ms音频；

实际时隙占空比和理论值一致约11*3.75ms/160ms = 25.7%；

2.4 连接开启通话

黄色框为esco包的rx+tx slot 1.25ms；绿色框 1ms为cpu上行语音处理电流，紫色框0.8ms为cpu下行语音处理电流；未标识波峰未rx空闲应答电流；

通话hfp的esco包为12slot 共7.5ms；推测esco包为'2-EV3'；

实际时隙占空比和理论值一致1.25/7.5 =16.7%；

3 BLE 蓝牙

我们先看下当前需求对于BLE蓝牙时隙的要求是咋样的；

BLE从1 == 手机	90 ms	11.2次	11.2*112  = 1255 bps	1600 bps /200 Bytes	2855 bps
BLE从2 == 码表	75 ms	13.4次	13.4*112 = 1501 bps	25000 bps /25K bps	26501 bps
BLE主1 == 指拨	数据交互完立即断开	7.5 ms间隔,交互6-10次	10*112 = 1120 bps	400bps /50 Bytes	1520 bps
BLE主2 == 尾灯	60ms	17次	17*112 = 1904 bps	1600 bps/200 Bytes	3504 bps

AirPkg = Preamble (1B) + Access Address (4B) + Header (2B) +  [ MIC(4B)加密可选] + Payload (27B) + CRC (3B)

最小空中包是10字节固定开销，通过抓包工具抓取后可能会附加上抓包工具的数据长度导致不是10字节而是26字节；

前导码（Preamble）	1 字节（LE 1M） 2 字节（LE 2M） 10 字节（LE Coded，80 bits）	用于接收机同步和自动增益控制
访问地址（Access Address）	4 字节	连接时为随机生成的值，广播为固定 0x8E89BED6
PDU 报头（Header）	2 字节（16 bits）	包含 LLID、SN、NESN、MD 及长度等信息
消息完整性校验（MIC）	4 字节（仅加密连接）	如果链路加密，这部分会附加在有效数据之后，算在有效负载内
CRC	3 字节（24 bits）	对整个 PDU 的校验

根据前面的BR的电流时隙推测，协议栈时隙不到30%使用率，

当前已经可以知道在EDR时隙上额外加35kbps的数据，额外50次connEvent，对于协议栈时隙而言，毫无压力；

虽然已经知道理论可行了，还是把测试结果补充完整，增加说服力些吧；

那就基于当前JL开发板，额外加个BLE模拟55次connEvent和35kbps数据传输；EDR正常工作时，ble从设备开启notify通知朝手机发送数据；

本小节先单独测试下只有ble时的电流时隙分布；后面小节再进行edr +ble 的二合一；

3.1 ble从设备连接时

保持连接但是没有数据交互时，配置connInterval连接间隔15ms，slaveLatency跳过次数0，每秒内connEvent交互次数66次；

3.2 ble从设备订阅后

实测当前sdk的链路层的空中包DLE(dataLenExtention)固定写死27, 修改无效，空中包单次connEvent一帧达不到251字节，payload仅27；

(单次connEvent最大Payload实际只有27，为当前 JL sdk 协议栈未优化；理论应支持单次connEvent 251 payload；)

节约connEvent使用一包att  69 Bytes有效数据 需要3个connEvent；每秒内有效数据66*69 =4554字节；

可知ble从 配置connIntrval连接周期15ms时，66cnt/s，4554Bytes/s；时隙占比约为2ms/15ms = 13.4%；

将第一个波峰放大后可知，每个tx约300us = 37字节 = Preamble (1B) + Access Address (4B) + Header (2B) + Payload (27B) + CRC (3B)，交叉验证ok；

4 EDR +BLE功能同时开启

4.1 BLE + 音乐播放时

结合音乐播放的2.3小节 +ble订阅数据的3.2小节，对比可知，当前蓝牙协议栈时隙占比约40%；

4.2 BLE + 通话

黄色框为hfp通话包的rx+tx slot；绿色框为ble发送数据的connEvent；

绿色框放大后可知，tx的持续周期约为350us，为单个connEvent，最大payload27字节，当前测试使用23Bytes；

前面当ble测试和 ble+音乐 时，单个connInterval内都有多个connEvent，

这里 ble+通话 单个connInterval只剩1个connEvent了；ble速率缩为3分之1；每秒内有效数据1800Bytes/s；

这里没有3个connEvent一起发或者扩展DLE，应该是这个芯片的JL sdk 闭源的协议栈部分没有对此优化，时隙本身十分充裕；

每15ms内有2个hfp slot 1.25*2ms，一个ble connEvent 1.25ms，时隙占空比3.75/15 = 25%；

5 小结

当前蓝牙协议栈实测ble和edr同时工作时，协议栈时隙使用率最大值只有40%；时隙不是问题；

当前方案主要风险点在于需要原厂提供二主二从的定制化sdk，并对ble的蓝牙协议栈进行参数优化；

猜测原厂需要修改的代码可能就是将当前2实例复制成多个实例，加些buff，特别是部分边界取值的参数需要注意下；然后就是拉通对齐；