BLE_HCI_CONNECTION_TIMEOUT with multiple connections as Peripheral

RE: BLE_HCI_CONNECTION_TIMEOUT with multiple connections as Peripheral

run_ar — Mon, 28 May 2018 12:28:48 GMT

Did you have this problem before you added the timeslot api as well? Please make sure you end the timeslot on time and that you do not have any operations that extend the given length of a timeslot or extension.

RE: BLE_HCI_CONNECTION_TIMEOUT with multiple connections as Peripheral

Cameron — Fri, 25 May 2018 19:37:19 GMT

We don't have an ellisys sniffer but we do have access to an Ubertooth One and several SDRs like USRP B210 so we could get some packet captures. I have looked at what connection parameters the phones were picking and they all seem to be in range, picking 30ms or 15ms with 4000ms timeout. I understand that as the number of open connections increases there will be some collisions and dropped packets. It just seems unlikely to me that there would be enough collisions to cause a BLE_HCI_CONNECTION_TIMEOUT. With a 30ms connection interval and 4000ms timeout, the peripheral would have to miss over 100 packets in a row for it to happen. I have also seen it connect and disconnect with that error in less than 4000ms. It happens with random connection handles at seemingly random intervals. Sometimes it is once in a while on a random device and sometimes its the same device connecting and disconnecting multiple times in a few seconds. This problem started showing up a lot more when we added the extra advertisement using the timeslot api.

RE: BLE_HCI_CONNECTION_TIMEOUT with multiple connections as Peripheral

run_ar — Fri, 25 May 2018 12:45:40 GMT

Do you have access to an ellisys sniffer so you can check what is happening on air? Also, if you have 3-4 open connections in the peripheral role, remember that the peripheral does not control the connection parameters. So even if a connection is about to time out and the priority is raised for that connection, there is a risk another central is transmitting at the same time and blocks the peripheral from receiving packets. Does the disconnect happen on a random connection handle or is it the same all the time?