Ble rare disconnection on softdevice with active timeslot session.

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Mon, 18 Sep 2017 11:46:00 GMT

Hi, it hard to say definitely now. I have to perform alot of tests. But subjectively, yes. It did help.

RE: Ble rare disconnection on softdevice with active timeslot session.

MartinBL — Fri, 15 Sep 2017 07:33:38 GMT

Did it help to use Timeslot priority NORMAL?

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Thu, 14 Sep 2017 12:00:00 GMT

"So you can try two things: Increase CST" - I cant, because iPhones rejects connection parameters update request if CST higher than 6s (confirmed in " Bluetooth Accessory Design Guidelines for Apple Products Release R7, 3.6 Connection Parameters")

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Tue, 12 Sep 2017 10:16:45 GMT

Thanks, the links are usefull for me! Yes sniffer was placed near nRF slave device. But my question was abot attempts of SD to mainanin connection. In lower part of your figure master does not update NESN bit, slave receive it and do not try to retransmit emediately but keeps slave latency enabled. And at same (as presented in log) behaviour the link range is better for SD connection than for my own stack connection. This fact pushed me to ask question here.

RE: Ble rare disconnection on softdevice with active timeslot session.

MartinBL — Tue, 12 Sep 2017 09:16:43 GMT

You can actually see that the Softdevice (Slave) answers your phone (Master), but as you walk out of range the phone stops hearing the Slave. Your sniffer seems to always be in range of the Slave and records everything.

Here is a good blog explaining the NESN mechanisms.

Regarding the Timeslot I suggest that you have a look at this documentation.

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Mon, 11 Sep 2017 11:24:01 GMT

Dear Martin Børs-Lind, I have done some research and have additional question. I updated my original question with sniffer log. The setup was as next: I placed sniffer near my nRF device( peripheral ) and connected it to the phone with nRFConnect. I walked away with phone until connection was broken. In log I did not seen any attempts of softdevice to maintain the connection. So what "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." is about? Could you explain into more details? Thanks

RE: Ble rare disconnection on softdevice with active timeslot session.

Martin Tverdal — Fri, 08 Sep 2017 07:12:13 GMT

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.

RE: Ble rare disconnection on softdevice with active timeslot session.

MartinBL — Fri, 08 Sep 2017 06:49:30 GMT

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.

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Thu, 07 Sep 2017 21:48:01 GMT

Thanks, i'll try. One more thing to clarify "high timeslot priority will impact the link quality" means decrease link qualify?

RE: Ble rare disconnection on softdevice with active timeslot session.

MartinBL — Thu, 07 Sep 2017 10:46:20 GMT

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.

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Tue, 05 Sep 2017 22:17:00 GMT

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?

RE: Ble rare disconnection on softdevice with active timeslot session.

Martin Tverdal — Mon, 04 Sep 2017 13:20:43 GMT

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?

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Fri, 01 Sep 2017 20:01:16 GMT

I use distinct sound notification on device at connection, disconnection and firmware start. So thats why I can exclude hardfault or reboot.I do not use sdk, but only "sd_ble_" level API. I do not caught reason yet because I can get it on peripheral side only, and device is not connected to debug interface. I think of passing this data to central over ble after reconnection. It occurs 2-3 times a day, sometimes at night.

RE: Ble rare disconnection on softdevice with active timeslot session.

MartinBL — Fri, 01 Sep 2017 15:49:52 GMT

I misread your question and assumed that by "logs on the central side" you were able to read out some debug messages from your peripheral device.

What SDK are you using?
On a BLE_GAP_EVT_DISCONNECTED event you can read out the reason with p_ble_evt->evt.gap_evt.params.disconnected.reason.
I use watchdog for 30s and seen logs on central side, it restores connection immediately Is this really a guarantee that you are not experiencing reboots or hard faults?
Can you estimate how frequently this occurs?

RE: Ble rare disconnection on softdevice with active timeslot session.

Valer_I — Fri, 01 Sep 2017 14:16:18 GMT

Hi,

8.0.0
I receive BLE_GAP_EVT_DISCONNECTED but do not know the reason yet. Just after I start advertising and central connect it back.
No, what logger are you talking about?
Long time connection without any "load" on central or peripheral device.

RE: Ble rare disconnection on softdevice with active timeslot session.

MartinBL — Fri, 01 Sep 2017 12:19:31 GMT

It seems strange that the connection is lost without any warnings, reboots, or hard faults at all.

What S110 version are you using?
Are you getting the BLE_GAP_EVT_DISCONNECTED event with any disconnect reason?
Do you get any useful information from the logger?
Are you staying in connection for a long time or connecting and disconnecting rapidly.