How to schedule multilink conect event?

[Lokher]

Hi

We are developing a system based on nrf desktop application of nRF Connect SDK 1.90. There are 4 devices  in this system: a dongle, a central device and two peripheral devices. Two peripheral devices connect to the central device with BLE, and the central device connect to the dongle with LLPM. We have managed to set up the connections, and encounter some problems when we tried to minimize the latency.

In our idea, two peripheral devices connect to central device with 7.5ms connect interval, peripheral 1 sends data during first 2.5ms of the connect interval, peripheral 2 sends data during next 2.5ms of the connect interval, and central device sends data during remaining.

However, we found that nrf desktop limit the minimal interval to 10ms with multilink

#if (CONFIG_CAF_BLE_USE_LLPM && (CONFIG_BT_MAX_CONN > 2))
 #define CONN_INTERVAL_BLE_REG		0x0008 /* 10 ms */
#else
 #define CONN_INTERVAL_BLE_REG		0x0006 /* 7.5 ms */
#endif

And below image shows the data timing, we can see there is 12.5ms between rx 0(perpheral 1) and rx 1(perpheral 2), and the inerval of same perpheral is 40ms.

Timespan between perpherals decreased  after changed SDC_DEFAULT_EVENT_LENGTH_US from 7500 to 2500, but same perpheral is still 40ms.

So, my question is how can two periperal send data in same conect interval and descrease same peripheral interval to 10ms?  

[tesc]

Hi,

In our idea, two peripheral devices connect to central device with 7.5ms connect interval, peripheral 1 sends data during first 2.5ms of the connect interval, peripheral 2 sends data during next 2.5ms of the connect interval, and central device sends data during remaining.

Based off of your drawing, it looks like there might be a misunderstanding regarding how BLE works. Each connection event, packets can go back and forth between the two connected peers, where one act as central and one act as peripheral. This means, to correct your drawing, the first 2.5 ms there will be alternating TX and RX on Peripheral 1 and on Central, for the communication between those two devices. Then similar for Peripheral 2 and Central the next 2.5 ms. Then TX and RX between Central and Dongle the next 1 ms.

The connections and connection events themselves are scheduled by the SoftDevice Controller subsystem, according to the documented Scheduling. Depending on the connection parameters, certain schedulings may or may not be possible.

For instance, you may have to consider the connection event length. Other activity, such as flash access, may lead to skipped connection events due to the CPU stalling during flash operation.

In general, three connections with 7.5 ms connection interval should be fully possible, at least if the same device act as central for all three connections, the event lengths are short enough, and there is still enough time for successfully scheduling any other timing-activity. (E.g. no concurrent scanning, advertising, etc.)

Regards,
Terje

[Lokher]

Thanks for reply.

I know that there is alternating TX and RX in one connection event, the central transmit at first 1.25ms, mostly is a polling packet, and peripheral transmit after it.

The test we did just include the central device and two pheripheral devices, and the central device was in neither advertising nor scanning after two BLE connections were set up.  I am curious why same peripheral interval is 40ms. Any idea?

[tesc]

Hi,

An easy way to figure out what is going on over the air, both with connection events, intervals and connection parameter setup, etc., is to do a sniffer trace. For instance, if you have a non-zero slave latency value then the peripheral can skip that number of connection events.

Regards,
Terje

[Lokher]

Hi tesc,

I used ellisys sniffer to catch air data, there are empty packets.in same interval, seems like  there was no data in the peripherals's buffer. Peripherals send data in "sent_cb", is it possible the callback is not invoked in time?

ellisys.btt

[tesc]

Hi,

There seems to be some devices not related to the four node setup, in that trace. Are the devices you are interested in the following?

Nordic_UART_Service x 2
60:BC:AA:3F:C0:6B (Resolvable)
6C:38:90:A0:03:AE (Resolvable)

And is the connection setup like the following?

According to the sniffer trace, the devices seem to have connection intervals of 10 or 20 ms.

On top of that comes slave latency, which means the peripherals can skip a number of connection events if they do not have any data to send.

A third aspect is that it is always the central of a connection that decides how to schedule the connection events. The connection interval is linked to the clock of the central, so a device acting as both peripheral and central (or multi-peripheral) will experience that the different connections drift relative to each other. If the connection intervals are the same for the three connections for the Multirole, it is therefore possible that the connection as peripheral drifts so that it overlaps with one or two of the connections as central.

In order to get better control of the connections, you could consider changing the setup, so that the Multirole is instead Multi-central, and the Central is instead a Peripheral 3. That way, all connection scheduling is done on the Multi-central and on the same clock (so you will not get drifting). With clock drift, you should expect the connections to slide slowly in and out of overlapping. When overlapping you should see some connection events dropped.

Regards,
Terje