nRF Connect: Multiple Connections to Same Peripheral

[awneil]

Developing a peripheral which supports multiple connections.

It's a pain to have to use loads of devices as centrals - is it possible for nRF Connect (Android) to make multiple connections to one peripheral ?

[Kenneth]

Haven't really tested that scenario, but an alternative can be that each time the peripheral start advertising you change the gap address, this will make the device appear as a completely different device.

1.  read current gap addr
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.0.1/group___b_l_e___g_a_p___f_u_n_c_t_i_o_n_s.html#ga0d859904dea45d4f0f4d5a95d9d65e78 

2. Increment byte 3 of gap addr (or other byte)
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.0.1/structble__gap__addr__t.html 

3. Write updated gap addr
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.0.1/group___b_l_e___g_a_p___f_u_n_c_t_i_o_n_s.html#gaef69dc212534adf4b78d211edce2267b 

4. Start advertisement.

[awneil]

But that would be modifying the production code simply to get around a limitation in the test tool ?

[Kenneth]

I can check with the mobile apps team, an alternative may also be to use the pc-ble-driver with an nRF52-DK:

https://devzone.nordicsemi.com/f/nordic-q-a/44603/how-to-connect-multiple-peripherals-to-one-central-by-using-pc-ble-driver-py-binding

Update: I checked with the mobile apps team; Android (or iOS) system manages the physical connection to a device. It only allows one. Apps can have multiple "virtual connections" to the same peripheral. Physical link is disconnected when the last virtual connection closes.

[awneil]

Thanks.

I can get by with 2 connections on desktop, plus 2 phones.

But these points remain:

1. Is it intended that the Android app should support multiple connections?
   If not, please add this as a feature request.
    
2. Is it intended that the desktop app should support > 2 connections?
   If it is, there's a problem - because it doesn't work;
   If it isn't, the UX is poor - it should give a better indication that ">2 connections is not supported"

[Kenneth]

1. The is a limitation by the OS (both Android and iOS), it does not allow more than one physical connection to the same peer.

2. It is not intended (or at least not designed or tested) to handle more than one physical connection to the same peer no.

Also see the Update I wrote on my previous reply.

[awneil]

OK thanks.

Perhaps I could make a feature request that the desktop version should support multiple connections to the same peer ?

[tesc]

Hi,

Another workaround could be to start multiple instances of the nRF Connect for Desktop BLE app, although admittedly that would require one Dongle or DK for each instance.

I have registered a feature request for supporting multiple concurrent connections to the same peripheral.

Regards,
Terje

[awneil]

I only have 1 dongle at the moment, so can't try that one - but it would be cheaper than buying more phones/tablets!

Do you happen to know whether a Raspberry Pi allows multiple connections to 1 peripheral ?

[tesc]

Hi,

I am afraid I do not know if Raspberry Pi allows multiple connections to 1 peripheral. I would think it depends on what stack you run on the RPi.

Please note the implications of testing multiple connections as peripheral to multiple centrals (on different devices) versus testing against multiple central instances on one device. Most notably, when connected to different centrals the connection events will sometimes overlap (due to clock drift on the centrals), while for multiple connections to the same central all connections run on the same clock and are scheduled not to overlap (to the extent permitted by connection parameters) by the central.

Regards,
Terje

[tesc]

Hi,

Testing with the latest version of the nRF Connect for Desktop BLE app, today I was able to run multiple concurrent connections to the Experimental: BLE Multiperipheral Application example of nRF5 SDK v17.0.2.

Please note that I did have to start a new scan in order for the "connect" button to enable again. Which kind of makes sense, since the listing is from the previous scan session, and you need a new scan to detect that the device started a new connectable advertising session after the listed one culminated in a connection.

Regards,
Terje