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.

[Karl Ylvisaker]

Hello,

hiroiwas said:

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

No worries - I try to understand as best I can, and then ask if anything is unclear.
Thank you for providing the diagram, and for your extreme patience with this.

Looking at the diagram it seems to me that your iPhone1 and iPhone2 also needs to have the central role for the scanning they do before starting to advertise.
If I could ask, why are they not always just advertising? Why do they need to pick up on the 'This device' advertising before they start their own advertising?
This is very expensive with respect to power consumption, since the scanning devices will need to be scanning 'constantly', which has a much higher current consumption than advertising.

An additional question is also; are you in control of the application running on the iPhone side of the link?

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.

Going back to this that you said earlier: is this all related to the 'this device' in the diagram?

Is the 'this device' battery powered, or is this a mains powered device?

Best regards,
Karl

[hiroiwas]

Hello Karl,

> Why are they not always just advertising? Why do they need to pick up on the 'This device' advertising before they start their own advertising?
This will be a requested specification from the customer.

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.

> Since the scanning devices will need to be scanning 'constantly', which has a much higher current consumption than advertising.
Since a iPhone always accepts iBeacons, I'm thinking of using it.

> Are you in control of the application running on the iPhone side of the link?
Yes, we also create control apps for the iPhone.

> Is this all related to the 'this device' in the diagram?
Yes, It will be the operation when "Advertising Start" in the figure is stopped.

> Is the 'this device' battery powered, or is this a mains powered device?
Of course, it is a mains power supply, and it will always operate without sleep.

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.