Relationship between monitoring timeout and connection interval

[hiroiwas]

I'm using S132 V.7.2.0 and trying to connect multiple devices simultaneously in a central role.

After starting the scanner, the connection operation bt the advertisement is started, and the BLE_GAP_EVT_CONNECTED event is restarting the scanner.
At this time NRF_SDH_BLE_CENTRAL_LINK_COUNT is set to 5. so it should be possible to connect up to 5 devices at the same time without disconnecting, but the next connection did not start until the first device is disconnected.

The parameters at this time are as follows.

ble_gap_conn_params_t
    .min_conn_interval  = MSEC_TO_UNITS(   30, UNIT_1_25_MS ),
    .max_conn_interval  = MSEC_TO_UNITS(   30, UNIT_1_25_MS ),
    .slave_latency      = 0,
    .conn_sup_timeout   = MSEC_TO_UNITS(  180, UNIT_10_MS ),

ble_gap_scan_params_t
    .active             = SCAN_TYPE_ACTIVE,
    .interval           = MSEC_TO_UNITS( 1000, UNIT_0_625_MS ),
    .window             = MSEC_TO_UNITS( 1000, UNIT_0_625_MS ),
    .timeout            = MSEC_TO_UNITS(    0, UNIT_10_MS ),
    .scan_phys          = BLE_GAP_PHY_1MBPS,
    .filter_policy      = BLE_GAP_SCAN_FP_ACCEPT_ALL,

As a result of trying various things, when It set

{ conn_params.conn_sup_timeout > scan_params.interval }

, and was able to connect the second and subsequent devices without disconnecting at the same time.

Could you please explain if my understanding that supervision timeout is related to connection interval is correct, and if so, how is it related?

I'm referring to past logs, the link "What are connection parameters?"

[hiroiwas]

Hello Karl,

> Are you saying that changing the connection parameters for your existing connection is affecting how you are receiving the ADV_REPORTs?
Yes it seems so.

In order to reproduce the phenomenon, I will modify the nordic example and attach it to support multiple connections.

1440.ble_app_uart_c.zip

The base software uses nRF5_SDK 17.1.0_ddde560/examples/ble_central/ble_app_uart_c.
The modified parts are that the instances of NUS_C and DB_DISCOVERY ware arranged by connection handle in order to support up to 5 simultaneous connections, and the scan start after connection is added to BLE_GAP_EVT_DATA_LENGTH_UPDATE.
I'm implementing scan parameters with the same parameters you presented in your initial question.(L.187-202)

When you run it, you can see that ADV_REPORT has stopped after connecting the first unit.
And if you change the conn_sup_timeout from 180ms to 2000ms, you can confirm that the second and subsequent units are connected without problems.

Of course, no error was returned by nrf_ble_scan_init.

From the above, do you know why ADV_REPORT stopped after rescanning?

Best regard.

[Karl Ylvisaker]

Hello,

Thank you for your extreme patience with this.

Looking further into this it could seem to be caused by the different priorities within the SoftDevice, which is to maintain a connection over scanning for new ones. The priority of the connection also increases as the connection is nearing timeout.
Therefore, if you are using a scan window that is larger than the connection interval in your connections it will be hard/not possible for the SoftDevice to schedule a full scan window inbetween the ongoing BLE connections.

However, if you reduce the scan window then it will be easier to interleave with the BLE Connections. So, for instance if you are using a connection interval of 100 ms, then you could try to use a scan window of 10 ms, to ease the scheduling.
If you still would like it to scan as much as possible you can set the scan interval to be equal to the new scan window value, so that the SoftDevice will attempt to schedule a scan window every time it does not conflict with a connection event.

These priorities could be the reason that you are seeing the choice of connection parameters influence your ADV_REPORTS received, since you are operating with a large scan window.

Best regards,
Karl

[hiroiwas]

Hello Karl,

Thank you for your inquiry.

I understand that this is a limitation due to the current SoftDevice design.

Thank you for your detailed reply.

[Karl Ylvisaker]

No problem at all, I am happy to help! :) 

While it is a feature of the priorities in the SoftDevice it might be possible to get around it by dividing the scan windows into smaller pieces, so that they will be easier to schedule between different connection events.
I hope this helps for your case.

Please do not hesitate to open another ticket if you should encounter any other issues or questions in the future! :) 

Best regards,
Karl