RE: How to schedule multilink conect event?

user115717 — Thu, 16 Jun 2022 02:46:35 GMT

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?

RE: How to schedule multilink conect event?

user8164 — Wed, 15 Jun 2022 15:31:19 GMT

Hi,

[quote user=""]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.[/quote]

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