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?"

[Karl Ylvisaker]

Hello,

and the BLE_GAP_EVT_CONNECTED event is restarting the scanner.

Do you have logging enabled? If so, is there an error code printed by the logger when this happens?
Please make sure to have DEBUG defined in your preprocessor defines like so:

This will make your logger output a detailed error message whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK. Please let me know what this error message reads, and which line of code it is pointing to.

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

Not quite - but a longer connection supervision timeout will give the SoftDevice a bigger chance to maintain the connection before it times out, which is likely what you are seeing here.
The real reason for this behavior is likely that when your scan window is equal to your scan interval you will attempt to scan continuously, which does not leave room to maintain your connections.
If you intend to connect to multiple peripherals (up to 5) I would recommend that you reduce the scan window to either half or less of the scan interval, to leave time for the SoftDevice to schedule and maintain the other connections as well.

Try this, and let me know if it improves on the behavior you describe.

Best regards,
Karl

[hiroiwas]

Hello Karl,
Thanks for your quick reply.
Sorry for the late reply as I was prioritizing other tasks.

First of all, enabled APP_ERROR_CHECK logging by the DEBUG defined, but the second connection failed with the presented parameters, and no error log was output.
As a test, when an appropriate error was issued with APP_ERROR_CHECK, an error log was output, so I think there is no problem with the log function.

Then, I tried setting the scan window to less than half the scan interval, leaving the supervision timeout at 180 ms.

( scan_params.interval, scan_params.window )
= ( 1000ms, 500ms ) ... 2nd device won't connect.
= ( 1000ms, 250ms ) ... 2nd device won't connect.
= ( 1000ms, 100ms ) ... 2nd device is connected.

And since the beacon (ADV_NONCONN_IND) interval was set as 100ms, advertising was stopped to eliminate the impact on the scheduler, but the result was the same.

I propose to add a log output within the API when the second unit cannot connect.
If so, please indicate where the logs should be added.

best regard.

[Karl Ylvisaker]

Hello,

hiroiwas said:

This will be a requested specification from the customer.

Aha, I see. I just wanted to point out that this is not the most power optimized approach, but if that's already considered and decided on then you can disregard the recommendation :) 

hiroiwas said:

Since the information is put in SCAN_RSP, it is considered for security reasons that we do not want it to be advertised unless it is necessary.

If I could ask, what kind of information is it that will be available in the scan response?
This information will be available to any device that sends a scan request in the time that the device is advertising, just so you know.

hiroiwas said:

Yes, we also create control apps for the iPhone.

Thank you for clarifying this.

In general, scanning will utilize the radio 100% of the scanning window, so if you need other tasks interleaved with this (like advertising) you need the scanning window to be smaller than the scanning interval, so that there is time inbetween the scanning to perform the other radio activity.

Best regards,
Karl

[hiroiwas]

Hello Karl,

> if you need other tasks interleaved with this (like advertising) you need the scanning window to be smaller than the scanning interval.

This matter is recognized as another problem, and for the time being, scan_interval=50ms and scan_window=40ms to see the situation.

Going back to my first question, why is it that the second device cannot connect (BLE_GAP_EVT_ADV_REPORT does not occur after restarting scanning) if the supervision timeout is set shorter than the connection interval?

Best regard.

[Karl Ylvisaker]

hiroiwas said:

Going back to my first question, why is it that the second device cannot connect (BLE_GAP_EVT_ADV_REPORT does not occur after restarting scanning) if the supervision timeout is set shorter than the connection interval?

The connection supervision timeout can not be shorter than the connection interval, as detailed in the following Bluetooth Spec requirement:

The Supervision_Timeout in milliseconds shall be larger than (1 + Conn_Latency) * Conn_Interval_Max * 2, where Conn_Interval_Max is given in milliseconds.

Do you not get an error when you attempt to set the connection supervision timeout so low?

Best regards,
Karl

[hiroiwas]

Hello Karl,

By the way, with scan_interval=1000ms,conn_sup_timeout=180ms conn_sup_timeout
I didn't get an error.

If there is a limitation you pointed out, I think it would have been better to receive it as a parameter error.

Best regard.

[Karl Ylvisaker]

Hello again,

hiroiwas said:

By the way, with scan_interval=1000ms,conn_sup_timeout=180ms conn_sup_timeout
I didn't get an error.

If there is a limitation you pointed out, I think it would have been better to receive it as a parameter error.

I do think you will receive this as a parameter error, if you attempt to set the connection supervision timeout lower than what is specified in the formula I linked earlier.

Scan interval does not really play into this formula, however. Which connection interval and slave latency did you use when you had a 180 ms connection supervision timeout?

Best regards,
Karl

[hiroiwas]

Hello again,

> Scan interval does not really play into this formula, however.
Hmmm?
If so, why did the ADV_REPORT event stop?

> Which connection interval and slave latency did you use when you had a 180 ms connection supervision timeout?
Same parameters as presented in the first question.
.min_conn_interval=30ms
.max_conn_interval=30ms
.slave_latency=0
.conn_sup_timeout=180ms

best regard.

[Karl Ylvisaker]

hiroiwas said:

> Scan interval does not really play into this formula, however.
Hmmm?
If so, why did the ADV_REPORT event stop?

Scan interval does not play into the formula for the relationship between the connection interval, the slave latency, and the connection supervision timeout. The scan interval does however play into how much of the time the device will be scanning for advertisements, but this is not related to the connection parameters.

I am not sure I fully understand your remaining question.
Are you saying that changing the connection parameters for your existing connection is affecting how you are receiving the ADV_REPORTs?

hiroiwas said:

Same parameters as presented in the first question.
.min_conn_interval=30ms
.max_conn_interval=30ms
.slave_latency=0
.conn_sup_timeout=180ms

Thank you for clarifying.

Best regards,
Karl

[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.