在相同的连接事件中是否可以返回BLE响应？

Question

使用BLE 4.1设备，是否可以在相同的时间间隔内接收对请求的响应（例如读取请求，读取blob请求）？

任务是在相同的连接间隔内读取超过20个字节：我正在开发一个应用程序，需要根据它们的值（非常低的延迟）读取这些字节并显示内容。我知道命令可以堆叠在同一个连接事件中，但在这种情况下这不适用。

我一直在阅读4.1规范没有成功。第3卷，规范4.1的第3.3.2-3.3.3节规定，在返回响应之前不得发出请求。如果确实必须等待连接间隔才能接收响应，则至少需要4个连接间隔来读取长属性（即超过20个字节）。

我在网上发现了几个讨论（1, 2），意味着在下一次连接事件中有响应，但是我还没有找到描述此行为的规范部分。

我希望能引用官方文档，而不是论坛或其他网站的解释。

Answer 1

答案是肯定的！但是在大多数实现中没有。

在每个连接事件中，主站和从站之间交替发送和接收数据包。主设备首先发送一个数据包，然后从设备发送数据包。如果这两个数据包没有任何要发送的内容，它们可能是空的每个数据包都包含一个标题位“更多数据”（MD），表示它想要发送另一个数据包。当两个连续数据包中的主机和从机都将MD位设置为0时，连接事件结束。

这意味着在从设备向主设备发送请求并且主设备最初不发送数据的情况下，主设备首先发送一个MD = 0的空数据包，从设备发送一个包含请求的数据包，其中MD = 0。在这种情况下，响应不会在相同的连接事件中发送。

但通常主人也是GATT客户。在这种情况下，主设备首先发送一个包含请求的数据包（MD = 0）。从设备收到该数据包后，必须在150（±2）微秒内回复数据包。如果固件已正确编程以在此时间范围内计算结果，则它可以在相同的连接事件中发送响应数据包。我设法用nrf52芯片自己做，我没有使用他们的softstack，但写了我自己的代码，直接与RADIO外设交互。然而，到目前为止，我还没有看到能够做到这一点的商业堆栈。

但是很多固件不幸被编程，即要发送的数据必须在它开始监听主数据包之前决定。这样的固件将不能在相同的连接事件中响应。但有时候，如果两端中的一端通过通知推送大量数据或者在没有响应的情况下写入数据，这会使连接事件保持打开状态，然后一些固件在连接事件启动后到达堆栈时实际发送数据包，但之前否则连接事件之前的几个数据包将会结束。

现在当我们谈论连接事件的最大长度时，HCI数据包“LE创建连接”中实际上存在一个参数，称为最小/最大连接事件长度，其中可以向控制器提示多少无线电时间它应该为此连接分配每个时间间隔。 Android将这些设置为0，这将使Broadcom芯片选择一个短的最大连接事件长度（如4-6包），但高通芯片将允许更长的连接事件。如果控制HCI数据包并将这些参数设置为等于连接间隔，则大多数芯片（包括Broadcom）实际上允许连接事件与间隔一样长。 Apple的Core Bluetooth似乎明确地将最大连接事件长度设置为一些较低的值，比如2-4毫秒，如果我没有忘记。我建议你不要使用Read Long特性过程（需要多个Read Blob请求和许多往返行程），而是简单地发送一个Write来告诉外设通过使用通知发送它所需要的尽可能多的数据（并因此在一个连接事件中堆叠多个通知）。