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,

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.