bluetooth-lowenergy - 具有BLE GATT特性的流数据传输方案

Question

BLE的GATT架构适用于固定的小数据块(每个特性最大20字节)。但是在某些情况下，您最终想要“流式传输”任意长度的数据，该长度大于20个字节。例如，即使您知道固件升级很慢，也可以进行固件升级。

我很好奇其他人采用了什么方案来通过BLE特性“流式传输”数据(即使数据量较小且速度较慢)。

迄今为止，我使用了两种不同的方案:

一种是使用控制特性，接收设备通知发送设备它已接收了多少数据，然后发送设备使用它来触发下一个不同特性下的写操作(我同时进行了with_response和without_response)。

我最近做的另一种方案是将数据基本上分成19个字节，其中第一个字节表示到达0时要遵循的数据包数量，这提示接收器可以将所有最近的更新串联并处理为一个数据包。

我正在寻找的答案类型是对有经验的人如何实现一个体面的方案的概述。并且可以证明为什么他们所做的是最好的(或至少更好的)解决方案。

Answer 1

在对现有协议(protocol)进行一些回顾之后，我最终设计了一种用于无线更新BLE外设的协议(protocol)。

设计假设

我们无法预测堆栈行为(协议(protocol)将用于我们所有的产品，无论使用什么芯片和供应商堆栈，无论是在外围还是在中央，都可能未知)，

使用标准GATT服务

避免L2CAP碎片

假设数据包在TX，

之前排队

假设可能有一些丢弃的数据包(即使堆栈不应该)，

避免不必要的数据包往返，

将代码复杂性放在中心位置

假定4.2增强功能不可用。

1表示2-5，6是性能要求，7是优化，8是可移植性。

整体设计

发现服务并读取了一些只读特征以检查设备与要上传的图像的兼容性之后，所有上载都发生在两个特征之间:

有效负载(仅写，无响应)，

状态(可通知)。

整个固件镜像通过有效负载特征按块发送。

有效负载是20字节的特征:4字节的块偏移量，再加上16字节的数据块。

状态通知告知是否存在错误情况，以及下一个预期的有效负载块偏移量。这样，上传者可以判断它是否可以推测性地继续进行，是否从自己的偏移量发送其块，或者是否应从状态通知中找到的偏移量恢复。

发送状态更新的原因主要有两个:

，当一切顺利时(有效载荷按顺序飞行)，以给定速率(例如4Hz，不是每个数据包都有)，

错误(乱序，一段时间后没有收到有效负载等)，具有相同的给定速率(也不在每个错误的数据包上)。

接收方希望所有块都按顺序排列，但不会重新排序。如果某个块发生故障，则将其丢弃，并推送错误状态通知。

进入状态时，它将隐式确认所有具有较小偏移量的块。

最后，在发送方一侧有一个发送窗口，许多成功的确认飞行使发送方能够扩大其窗口(在匹配确认之前发送更多的块)。如果发生错误，窗口将减少，丢失的块可能是由于某个地方的队列溢出。

讨论

6.由于ATT协议(protocol)明确告诉已确认的PDU(写，指示)不得流水线(即，除非收到响应，否则您不能发送下一个PDU)，因此避免使用“单向” PDU(写而没有响应和通知)。

状态，包含最后收到的数据块，缓解5。

为了遵守2.和3.，有效负载是20字节的特征写入。 4 + 16具有许多优点，一个是使用16字节块的偏移量验证仅涉及移位，另一个是块始终在目标闪存中进行页面对齐(最好是7)。

为了应付4.，在接收状态更新之前发送了多个块，推测将正确接收。

该协议(protocol)具有以下功能:

它适应 radio 条件

它适用于发送方的队列

没有来自目标

的状态泛洪

队列保持填充状态，这允许整个中央堆栈使用所有可能的TX机会。

一些参数不在此协议(protocol)中:

Central应该强制缩短连接间隔(尝试在更新程序应用中强制执行)；

从属PHY应该表现得很好，具有从属延迟(YMMV，测试供应商的堆栈)；

您可能应该压缩有效负载以减少传输时间。

号码

和:

15％压缩，

与connectionInterval = 10ms连接的设备，

一个主PHY，它将每个连接事件限制为4-5个TX数据包

平均广播条件。

我平均每个连接事件得到3.8个数据包，即丢包，协议(protocol)开销等之后约6 kB/s的有效负载。

这样，在不到10秒的时间内完成了60 kB图像的上传，整个过程(连接，发现，传输，图像验证，解压缩，闪烁，重启)在20秒内完成。