在相同的連接事件中是否可以返回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來告訴外設通過使用通知發送它所需要的儘可能多的數據（並因此在一個連接事件中堆疊多個通知）。