Multiperipheral & IOS Not Connection issue

[Aser]

Hello, I want to use Multiple Connection (Multiperipheral sample) to connect with multiple IOS phones at the same time to implement UART.
Currently, up to 9 units are set up.
However, up to two units are connected well, but the third connection occurs simultaneously with Connection for two reasons below.
BLE_HCI_CONNECTION_TIMEOUT
BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT
Why is the elapsed time exceeded and what is the solution?

SDK : nRF5_SDK_13.0.0_04a0bfd
Softdevice : s132_nrf52_4.0.2_softdevice
MCU : nRF52832

IOS : Central

Device : Peripheral

[Einar Thorsrud]

Hi,

A key think here is that when the nRF is peripheral and the phones are centrals, all the connections will be completely independent as the scheduling is entirely up to the central and they have no way to know about each other. So you will see collisions in time when there are multiple connection events at the same time. The more active connections you have, the more this will be and the worse the performance. So this is inherently a configuration that will give you bad performance.

That said, it could still be good enough if you can live with a low data rate and high latency. Then in order to make this work you need to have a lot of slack in your connection parameters (slow connection interval, short event length, long supervision timeout compared to connection interval) and exchange very little data. You could also try to swap the roles, making the nRF central and the phones peripherals. That may also give you problems if the phones do a lot of other 2.4 GHz activities though, such as streaming Bluetooth audio, lots of Wi-Fi traffic etc.

[Aser]

@Einar Tharsrud: Thank you very much for your kind reply.
What you're saying is that a lot of work is done simultaneously, resulting in poor performance.
Is that why you are saying Disconnection?
Then what should I do to prevent this phenomenon?

[Einar Thorsrud]

You should ensure there is a lot of slack, meaning use a long connection interval, short event length and long connection timeout. And send little data. Alternatively you could consider reversing the roles, so that the nRF is the central and the iPhones are the peripherals. That also has some down-sides, but it may be better in this use case where the nRF needs to stay connected to many iPhones.