使用CC2540加密狗的BTool与Python Bleak读取BLE数据结果不一致

问题背景 #

我用Bleak编写了如下代码实现BLE设备数据读取：

characteristic_data = "0000ff31-0000-1000-8000-00805f9b34fb"
characteristic_command = "0000ff21-0000-1000-8000-00805f9b34fb"

def start():
    await self.client.start_notify(characteristic_data , cb1)
    await self.client.start_notify(characteristic_command, cb2)
    await self.client.write_gatt_char(characteristic_command,bytearray([0x80, 0x04, 0x15]),response=True) # 发送启动数据传输的命令

def cb1():
    await self.client.write_gatt_char(characteristic_command,bytearray([0x80,0x04, 0x17]),response=False) # 发送ACK告知设备已接收，请求更多数据

def cb2():
    await self.client.stop_notify(characteristic_command)

代码运行正常，获取到的长数据包示例为：32088200001303D9011303CD011203CE011C03CC010000。

而使用CC2540加密狗配合BTool操作时，流程为：

• 在0x001D和0x0022（对应UUID为0xFF21和0xFF31特征值的Client Characteristic Configuration Descriptor）写入01:00以开启通知
• 向0x001C（UUID为0xFF21）写入0x80, 0x04, 0x15启动数据传输
• 从0x0021（UUID为0xFF31）获取数据

此时获取到的同类型长数据包比Bleak结果少3字节，示例为：3217F80000790327027503270276031D02890320。短数据包在两种方式下长度一致，仅长数据包出现截断。

核心原因分析 #

1. BLE分段数据包的自动处理差异 #

BLE长数据包需要通过ATT协议分段传输，不同工具对分段包的拼接逻辑不同：

• Bleak内部会自动处理ATT分段数据包的拼接，将多个分段合并为完整的长数据后再传递给回调函数，所以你拿到的是完整数据。
• BTool默认可能不会自动拼接分段包，仅显示单个ATT包的内容。你看到的“少3字节”的数据包，可能只是长数据的第一个分段，后续分段未被合并显示。

2. ACK触发时机的影响 #

你的Bleak代码中，cb1回调会在收到characteristic_data的通知后立即发送ACK（0x80,0x04,0x17），这个ACK会触发设备继续发送后续分段数据，Bleak则持续接收并拼接所有分段。
而在BTool操作中，若没有及时发送对应ACK，设备可能不会发送最后一段3字节的数据，或者BTool未捕获到后续分段。

3. MTU协商的差异 #

• Bleak会自动与设备协商最大传输单元（MTU），通常会协商到较大的MTU值（比如256字节），长数据包可能只需一次或少量分段即可完成传输，降低了分段丢失的概率。
• BTool可能使用默认的小MTU（比如23字节），长数据包需要更多分段传输；若BTool的接收逻辑存在遗漏，就会出现数据截断。

4. 配置细节的隐性差异 #

虽然你在BTool中手动设置了CCCD为01:00（开启通知），和Bleakstart_notify的默认行为一致，但Bleak在启动通知时可能还执行了其他隐性操作（比如重新确认连接参数、MTU协商），这些操作会影响设备的数据包发送策略。

验证建议 #

• 查看BTool的完整接收日志，确认是否存在多个分段数据包，将它们手动拼接后对比Bleak的结果。
• 在Bleak代码中手动设置MTU为23（BTool默认值），测试是否会出现同样的数据截断问题。
• 在BTool中模拟Bleak的ACK时机，收到第一个数据包后立即发送0x80,0x04,0x17，观察是否能获取完整数据。

内容的提问来源于stack exchange，提问作者Rony Tesler