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
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?
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?
HI, I faced the problem with android phone and windows 10 centrals. I have to enable logging on central to get the disconnection reason. Answer to second question ci: 30ms, sl:25, cst:6s. And the third question make me think to do some code review. At connection I always use high priority in connection abnd timeslots length are about 2500us, timeslot extention not implemented.Could high timeslot priority have impact on softdevice's connection?
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.
Thanks, i'll try. One more thing to clarify "high timeslot priority will impact the link quality" means decrease link qualify?
Yes, decrease. The Softdevice will voluntarily drop packets to service timeslots instead, and a BLE link can only lose so and so many packets before the link breaks.
Just want to clarify. If the SoftDevice will not drop any packets it considers important to service a HIGH priority timeslot. It will only voluntarily drop what it considers as un-important packets.
