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:

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

No problem at all, I am happy to help! :) 
We will continue this whenever you have the chance, no worries.

hiroiwas said:

but the second connection failed with the presented parameters, and no error log was output.

When you say that the second connection failed, does that mean that a reset occurs, or just that the second connection never happens at all?

hiroiwas said:

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.

You mention beacon here, and the ADV_NONCONN_IND - is your second device you are trying to connect with a beacon?
A beacon refers to an advertising device that is only ever advertising as non-connectable, i.e it is not open to establishing any connections, is this what you mean when you say beacon as well?
In the case that this is what you mean there is no impact of the central device's scanning parameters, since the connection will not be established anyways.

Perhaps I am not understanding your setup correctly. Do you use the same firmware for all your peripheral devices?
What are the advertising parameters you are using in your peripheral firmware?

Additionally I now notice that you are using a Connection Supervision Timeout of 180 ms, could you elaborate why you are using such a small Connection Supervision Timeout - is it important that the connection is terminated as soon as possible if the devices should fall out of range?

Best regards,
Karl

[hiroiwas]

Hello Karl,

Failure of the second connection means that the second connection did not occ

The mention of beacons was poorly explained.

Our device has central and peripheral roles.
The primary role is central, but the peripheral role beacons periodically.

A connected external peripheral catches the beacon, fires ADV_IND, and connects with the external peripheral caught by the scanner.
The beacon of the device only emits at the cycle set at the start, and there is no connection with the external central by the peripheral role.

The beacon parameters at this time are as follows.

ble_gap_conn_params_t
    .min_conn_interval  = MSEC_TO_UNITS(   50, UNIT_1_25_MS ),
    .max_conn_interval  = MSEC_TO_UNITS(   50, UNIT_1_25_MS ),
    .slave_latency      =                   0,
    .conn_sup_timeout   = MSEC_TO_UNITS( 4000, UNIT_10_MS ),

Suspecting that the beacon advertising schedule was impacting the scan window schedule, I turned off the beacon, but it didn't seem to have any effect.

Regarding the connection supervision timeout of 180ms, the connection interval was set to 30ms according to the specifications of the connected device (iPhone), and the connection supervision timeout was made 6 times the connection interval as recommended.
The central role settings are based on the settings of the connected device.

Best regard.

[Karl Ylvisaker]

Hello,

Thank you for your patience with this, and for elaborating and clarifying about the use of 'beacons'.

hiroiwas said:

The primary role is central, but the peripheral role beacons periodically.

A connected external peripheral catches the beacon, fires ADV_IND, and connects with the external peripheral caught by the scanner.
The beacon of the device only emits at the cycle set at the start, and there is no connection with the external central by the peripheral role.

I understand that you mean them to advertise when you say that the peripherals will beacon?
If this is not what you mean, could you perhaps provide a diagram to explain the topology of your application, and the roles/modes of each device?

hiroiwas said:

Suspecting that the beacon advertising schedule was impacting the scan window schedule, I turned off the beacon, but it didn't seem to have any effect.

Do you have any logs you could share from the devices when you suspect that advertising is not restarted?

Best regards,
Karl

[hiroiwas]

Hello Karl,

The translation doesn't seem to convey my intentions very well.

Can you make sense of the situation in the diagram below?

Best regard.