Ble rare disconnection on softdevice with active timeslot session.

[Valer_I]

Hi, During testing I noticed rare BLE connection loses with Softdevice S110 when timeslot session is active. It is hard to catch them with sniffer due to rare behaviour. So the question is about ever known reasons of connection loses while timeslot session is enabled. Note: No reboot/hardfault occured because I use watchdog for 30s and seen logs on central side, it restores connection emmediately.
Thanks.

UPDATE: SD_LINK_STABILITY.pcapng

[Martin Tverdal]

Hi, Disconnects does not have to be a symptom of a bug in code. It can just be that the link was lost due to noise in the environment. To rule this out it would be very interesting to know the disconnect reason. Maybe it is just BLE_HCI_CONNECTION_TIMEOUT? It is interesting to know the disconnect reason on both sides. What is you central side? A phone? It should report a disconnect reason too, and it would be helpful in order to understand what is going on.

Second question: What connection parameters are you using? What is the connection interval? What is slave latency? And what is supervision timeout?

Third question: How are you using the timetlot API? Do you ever use NRF_RADIO_PRIORITY_HIGH? or always NRF_RADIO_PRIORITY_NORMAL? What is the longest timeslot length in us you request? And do you use the feature to extend the timeslot once you are in it?

[MartinBL]

When you are using the Timeslot API your are allowing the Softdevice to exploit slave latency and supervision timeout and skip certain BLE events if they coincide with a scheduled timeslot event.

When the Softdevice notices that a connection is approaching supervision timeout though, it will disregard all time slots, regardless of their priority level, to maintain the connection. This is because keeping the BLE link alive always has priority over the timeslot API. If your timeslots have priority NORMAL however, the Softdevice will discard all timeslot events that coincides with BLE events. So yes, a high timeslot priority will impact the link quality. Your CST is also relatively short, so if the Softdevice skips a few BLE events to run timeslot events, you get vulnerable to disconnects due to packet loss. So you can try two things: Increase CST and use timeslot priority NORMAL.