Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Sigurd — Mon, 09 May 2022 13:01:13 GMT

Hi,

Sorry for the delay.

[quote user="Gaetan"]Do you think that there could be a solution on the central to add a variable time between the reception of the avertising and the sending of the connection request?[/quote]

No. Not on the link-layer. But you can add some delay for when you call sd_ble_gap_connect(). The advertiser will have the radio in RX mode in a short period after sending the advertising packet. The central/scanner need to send the connection request packet in this short window after receiving the advertising packet. If you add some sending delay here, the advertiser will not receive the connection request(because the radio is no longer in RX mode). When you call sd_ble_gap_connect(), the central will listen/scan for a advertising packet(from the address you set when calling the connect function), and it will send the connection request packet if it receive a advertising packet from the specified address.

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Gaétan — Mon, 28 Mar 2022 07:11:12 GMT

For the moment, we regularly observe the situation of synchronization of the centrals during 2 or 3 seconds.
Do you think that there could be a solution on the central to add a variable time between the reception of the avertising and the sending of the connection request?

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Gaétan — Mon, 14 Mar 2022 10:13:15 GMT

Hello,

I'm sorry, but I don't think that the start time of the SCAN function is important.
Indeed, what matters is how many centrals are listening on the channel at the moment the peripheral is advertising.

I really feel that the problem is that several centrals are TX their response to the advertising in a perfectly synchronized way.
In this case, it would be necessary to integrate a random time in the central between the RX of the advertising and the TX of the connection request.

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Sigurd — Wed, 09 Mar 2022 12:21:38 GMT

Hi,

[quote user="Gaetan"]but I was worried that softdevice wouldn't like too long a delay in interupt time[/quote]

Yeah, better to use an app_timer for this. Start a one-shot timer that expires in random time < from 0 to x ms>, and in the callback, start the scanner.

If it's started with some delay, then it reduces the probability for the scanners to be on the same channel.

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Gaétan — Fri, 04 Mar 2022 10:54:30 GMT

[quote userid="15146" url="~/f/nordic-q-a/85124/concurrents-connections-2-identicals-centrals-try-to-connect-to-the-same-peripheral-at-the-same-time/356212#356212"]For both central and peripheral?[/quote]

I think the peripheral program is not in question because when the centrals synchronize, the peripheral does not report any status, it looks like it does not receive a coherent frame. Probably because the 3 centrals transmit perfectly at the same time and the frame received is corrupted.

I tried putting the same delay in ms (but I was worried that softdevice wouldn't like too long a delay in interupt time). It didn't change anything because I have the feeling that the moment of the scan start is not very important, what is important is that the 3 centrals are listening on the same channel and simultaneously receive the advertising of the peripheral... Then the 3 centrals respond in a perfectly synchronized way!

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Sigurd — Fri, 04 Mar 2022 09:12:05 GMT

[quote user="Gaetan"]I tried with SDK 17.1 and softdevice 7.3.0.[/quote]

For both central and peripheral?

[quote user="Gaetan"]tried to add nrf_delay_us[/quote]

Could you try a bit bigger delay? use e.g. nrf_delay_ms() instead?

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Gaétan — Wed, 02 Mar 2022 07:07:53 GMT

Hi,

1) Yes disconnect reason is BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED(0x3E)

2) Actualy project use s140_nrf52_6.1.0_softdevice.hex, I need to change SDK version...

3) Yes, I tried to add nrf_delay_us(NRF_FICR->DEVICEADDR[0] & 0xFF); in case BLE_NUS_C_EVT_DISCONNECTED without change.

Regards,

Edit: I tried with SDK 17.1 and softdevice 7.3.0... It is the same: the dongles synchronize for a few seconds (about 3 seconds) and then the operation is OK

RE: Concurrents connections (2 identicals centrals try to connect to the same peripheral at the same time)

Sigurd — Mon, 28 Feb 2022 08:42:54 GMT

Hi,

1) When you get the BLE_GAP_EVT_DISCONNECTED event, what is the disconnect reason? BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED(0x3E)?

2) What SD version is this? Do you see the same issue with the latest SoftDevice version? 7.3.0?

[quote user=""]generates a BLE_NUS_C_EVT_DISCONNECTED event with which I relaunch a scan_start[/quote]

Do you see the same issue if you add a random delay before calling scan_start?