Multilink Relay for Separate BLE control

[PinkSquirrel]

Hi, I am currently utilizing an app that supports multi link; however, I was only able to get 7 maximum stable connections. My goal for this multi-link is to connect a sensor, and if the sensor values reach a certain value, a pin for that certain peripheral will be set to high (LED On) in this case. I was wondering if separate communication for each peripheral is possible for a multilink relay; if my memory serves correct, if the central sends a command, all of the connected peripherals receive the command. I want a specific peripheral to recieve the command from the central relay nrF based on condition, but I am not sure if this is possible. On the app, I had to create a mutable hashmap where I saved each GATT and GATT Characteristic for each peripheral separately to acheive this kind of communication. 

Thankyou

[Einar Thorsrud]

Hi,

This issue is probably due to problems with the scheduling, and perhaps too tight connection parameters.

In the first case, where you have a central that connects to many peripherals, the central can schedule the links in  smart way so that the connection events do not collide (within the limits of what is possible with the given parameters and number of links). This is possible as it is the central that dictates the scheduling.

Now, when the central suddenly also acts a peripheral it is the other central that decides when the connection events for that link is, and the connection parameters as a whole (though the peripheral can request changes to parameters). This makes things much more difficult for the multilink/multirole device, and as there is no coordination between the two, the performance could vary from time to time.

For this to work better it is good to first of all get a understanding of how much time is actually left for the peripheral link, when you already have 7 central links. What is the connection interval, and what is the event length? You should have a good margin here, both for scanning and advertising, and for maintaining the peripheral link. Give as much slack as possible here. Also, use a long supervision timeout so that you can have quite a bit of packet loss without causing problems.