使用BLE 4.1设备，可以在同一时间间隔内收到对请求的响应（例如读取请求，读取blob请求）吗？
任务是在相同的连接间隔中读取超过20个字节：我正在开发一个需要读取这些字节并根据其值显示内容的应用程序（具有非常低的延迟）。我知道命令可以堆叠在同一个连接事件中，但在这种情况下不适用。
我一直在仔细阅读4.1规范。第3卷，规范4.1的第3.3.2-3.3.3节规定在返回响应之前不应提出任何请求。如果确实必须等待连接间隔来接收响应，则至少需要4个连接间隔才能读取长属性（超过20个字节）。
我在网上发现了几个讨论（1，2），暗示在下一个连接事件中会出现响应，但我没有找到描述此行为的规范部分。
我希望得到的解释是引用官方文档，而不是论坛或其他网站。
答案 0 :(得分：3)
答案是肯定的！但在大多数实施中都没有。
在每个连接事件中，主设备和从设备在发送和接收数据包之间交替。主设备通过发送数据包开始，然后从设备发送其数据包。如果没有任何内容要发送，则两个数据包都可能为空。每个数据包包含一个标题位“更多数据”（MD），表示它想要发送另一个数据包。当主设备和从设备在两个连续数据包中将MD位设置为0时，连接事件结束。
这意味着在从设备向主设备发送请求并且主设备最初没有任何内容要发送的情况下，主设备首先发送MD = 0的空数据包，从设备发送包含MD = 0的请求的数据包。在这种情况下，响应将不会在同一连接事件中发送。
然而，通常主人也是GATT客户。在这种情况下，主设备通过发送包含请求的数据包（MD = 0）开始。从机收到该数据包后，它必须在150（±2）微秒内回复数据包。如果固件被正确编程以在该时间帧内计算结果，则它可以在相同的连接事件中发送响应分组。我设法用一个nrf52芯片自己做，我没有使用他们的软件堆栈，但编写了我自己的代码，直接与RADIO外设交互。然而，到目前为止，我还没有看到任何商业堆栈能够做到这一点。
但遗憾的是，许多固件的编程方式是，即使在开始收听主数据包之前，也必须决定要发送的数据。此类固件将无法在同一连接事件中响应。然而，有时如果两端中的一端通过通知推送大量数据或者没有响应而写入，这将使连接事件保持打开，然后一些固件实际上可以在连接事件开始后到达堆栈时发送数据包，但之前否则，连接事件之前的一些数据包将结束。
现在当我们谈论连接事件的最大长度时，HCI数据包中的实际上有一个参数“LE Create Connection”，称为最小/最大连接事件长度，其中一个可以向控制器提示它有多少无线电时间应该为每个间隔分配这个连接。 Android将这些设置为0，这将使Broadcom芯片选择短的最大连接事件长度（如4-6个数据包），但另一方面，Qualcomm芯片将允许更长的连接事件。如果控制HCI数据包并将这些参数设置为等于连接间隔，则大多数芯片（包括Broadcom）实际上允许连接事件与间隔一样长。 Apple的核心蓝牙似乎明确地将最大连接事件长度设置为某个较低的值，如果我没有忘记，则为2-4毫秒。
我建议你永远不要使用Read Long Characteristics程序（需要多个Read Blob请求和多次往返），而是简单地发送一个Write来告诉外围设备，通过使用通知，发送所需的数据（和因此，在一个连接事件中堆叠多个通知。）