Distribution of connection intervals for multiple connections.

[Yury Morgunov]

Hi all!

I'm trying to figure out how softdevice distributes connection intervals on multiple connections.

The test scheme for connecting devices is as follows: 
Devices 2,3,4 looking for advertising from 1 and connect to it.

For simplicity, I have set the following connection options:

• NRF_SDH_BLE_GAP_EVENT_LENGTH = 16
• NRF_SDH_BLE_TOTAL_LINK_COUNT = 5
• max_conn_interval = 100 ms
• min_conn_interval = 100 ms
• slave_latency = 0

All three devices connected with phy coded, DLE=251 bytes, MTU=247 bytes, checked the settings after connection:

• max_rx_octets = 251
• max_tx_octets = 251
• max_rx_time = 2704 us
• max_tx_time = 2704 us

Currently using NRF SDK 17.1 and s140_nrf52_7.2.0_softdevice.
I would update but don't know how yet as Nordic doesn't update the sdk anymore.

After reading the documentation, I concluded that the connection interval for device number 1 will be distributed evenly, every NRF_SDH_BLE_GAP_EVENT_LENGTH * 1.25 milliseconds.
However, in practice, I get a random distribution of intervals.

On every reboot of devices 2,3,4 I get a random position of connection intervals that are not a multiple of NRF_SDH_BLE_GAP_EVENT_LENGTH * 1.25 ms and sometimes conflict.

This is important to me for three reasons:

1. I cannot guarantee that I will be able to send N packets per interval.
2. Because of this, the speed drops and it becomes unpredictable.
3. Since I will not always be able to transfer the entire packet for the connection interval, the packet transfer delay increases.

So my question is why is this happening?
Can this be managed somehow?
How does it really work?
Does this only work for when the central device has multiple connections?

[Sigurd]

Hi,

Take a look at the text here:

https://infocenter.nordicsemi.com/topic/sds_s112/SDS/s1xx/multilink_scheduling/suggested_intervals_windows_s112.html

In short, Peripheral link timing-events follow the timings dictated by the connected peer. The Peripheral does not influence this scheduling.

I concluded that the connection interval for device number 1 will be distributed evenly, every NRF_SDH_BLE_GAP_EVENT_LENGTH * 1.25 milliseconds.

This only applies to central links. I.e. if e.g. device #1 is Central, and Device #2-4 is Peripheral.

Does this only work for when the central device has multiple connections?

Correct.

[Yury Morgunov]

Sorry for the long reply, I had a long weekend.

Thank you! It's a pity that it works this way.
It is interesting that having the same timer counter on all nodes, I could independently specify the moment for the connection interval, so the question arises, can I shift the connection interval from the side of the central device?

[Yury Morgunov]

To be honest, I don't know how the connection interval should behave in this case.
But I tried to change the connection interval in the process, but it did not help.

[Sigurd]

Yeah, collision free scheduling can not be guaranteed in this topology.

Maybe you can change your topology, so that device #1 is Central, and device #2-4 is Peripheral.

[Yury Morgunov]

The next experiment was this scheme:

It turns out that I have no way to synchronize the connection interval between 1<->2 and 2<->3. It's a pity because I can't fully use the radio channel. 
Any ideas? For example, in such a topology, we have two connections 1 <-> 2 and 2 <-> 3 that are controlled by the master, it turns out that he must have the authority to manage the connection interval and, in theory, shift as I need it.

[Sigurd]

Hi,

Are all devices here using nRF52840 and S140?

[Yury Morgunov]

Yes

[Sigurd]

I think if Central(#1) first connects to peripheral(device#2), and then after that, Central(device#2) establishes connection to Peripheral(device#3), you will initially have a collision free scheduling. 

[Yury Morgunov]

It looks pretty random:

The color blue is device number 2.
Yellow number 3.

• NRF_SDH_BLE_GAP_EVENT_LENGTH = 32
• NRF_SDH_BLE_TOTAL_LINK_COUNT = 5
• max_conn_interval = 80 ms
• min_conn_interval = 80 ms
• slave_latency = 0

I expected a step of 40ms, so I set the connection interval to 80ms.
However, the connection interval has been increased, and a new connection is set up at a random time.

I also tried enabling and disabling extended connection events. It didn't solve the problem.

  APP_ERROR_CHECK(nrf_sdh_ble_enable(&ram_start));

  ble_opt_t opt{};
  opt.common_opt.conn_evt_ext.enable = 1;
  APP_ERROR_CHECK(sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt));

[Sigurd]

Hi,

Yury Morgunov said:

• NRF_SDH_BLE_GAP_EVENT_LENGTH = 32
• NRF_SDH_BLE_TOTAL_LINK_COUNT = 5
• max_conn_interval = 80 ms
• min_conn_interval = 80 ms
• slave_latency = 0

Are you getting any packet drop here?

If you take a sniffer trace(with nrf sniffer), do you see packet drop, i.e. connection events where no packets are sent?

[Yury Morgunov]

Let me explain a little more.
As I understand it, the central device for setting the connection interval guarantees itself a radio channel time of NRF_SDH_BLE_GAP_EVENT_LENGTH.

Based on this image:

I can say that the central node number 2 will skip the connection interval between 2 <-> 3 if it falls into the connection interval between 1 <-> 2 with the size NRF_SDH_BLE_GAP_EVENT_LENGTH.

In tests, I found out that the start time of the connection interval between 2 <-> 3 will be random (connection 1 <-> 2 was already active). So there is a chance that the connection interval between 2 <-> 3 will sometimes be ignored. This is what I got in the picture two posts above, mistakenly thinking that the connection interval had increased.

It turns out that in such a scheme, softdevice does not use transmitWindowOffset to correct the start time of the connection interval, but prefers to simply ignore the connection interval if they conflict.

Here is an example where the connection interval between 2 <-> 3 conflicts with 1 <-> 2.

• NRF_SDH_BLE_GAP_EVENT_LENGTH=32
• max_conn_interval = 160 ms
• min_conn_interval = 160 ms

Here is an example when there is no conflict:

Here is the behavior when I deliberately reduced the connection interval between 2 and 3:

Now it is not clear to me why the softdevice does not correct the start time of the connection interval and how can this be fixed?

[Yury Morgunov]

I spent all day and couldn't run the sniffer. Due to the fact that the firmware did not respond to pings from SnifferAPI/UART.py. Something is wrong with the firmware. Perhaps I will create a separate topic on the problem.