Trouble with non-concurrent multiple peers

RE: Trouble with non-concurrent multiple peers

operator — Wed, 24 Jan 2018 19:51:12 GMT

That is worth keeping in mind, thanks Aleksander.

RE: Trouble with non-concurrent multiple peers

Aleksander Nowakowski — Wed, 24 Jan 2018 19:01:15 GMT

My point was, that if you have nRF Connect running in background while you test your app, and disconnect from the device in your app, you'll get onConnectionStateChanged with State disconnected, but nRF Connect may keep the physical connection if it wasn't excited with back button and had gatt server enabled. Then your device wouldn't advertise again, as it's still connected to this Android device. If you are sure that nRF Connect is properly closed (there is no notification saying that nRF Connect's service is running), and you will have this problem, check if you disconnect from all BluetoothGatt objects (in case you connected multiple times to the same device). I can't find any other reason why wouldn't it works with your app and would with nRF Connect.

RE: Trouble with non-concurrent multiple peers

operator — Wed, 24 Jan 2018 18:40:38 GMT

Hello Aleksander. This is good to know but the issue is not with nRF Connect, which works just fine.

The issue is what might cause this behavior in a custom iOS/Android application?

RE: Trouble with non-concurrent multiple peers

Aleksander Nowakowski — Wed, 24 Jan 2018 12:48:22 GMT

Make sure you don't have nRF Connect running in ht background (there is no nRF Connect notification) when you connect in your app. nRF Connect, when you have GATT Server enabled in it, may overtake the connection so when you disconnect in your app the physical connection is still open as nRF Connect is still connected. To avoid this close nRF Connect with BACK button, not just switch to another app. You may also disable the GATT server there (drop down menu and DISABLE icon). If you have it open, and you disconnect from your app, switch back to nRF Connect and disconnect there, then you should be able to connect on another phone as the physical connection will be closed (unless some other app also is connected like nRF Connect, not likely). This issue will no longer bother you on Android 8.1+, as then the background connection is done as opportunistic (like a weak reference).

RE: Trouble with non-concurrent multiple peers

operator — Wed, 24 Jan 2018 01:11:49 GMT

Hi Petter and thanks for your response.

It appears that this issue may be related to our custom app as nRF Connect is able to connect on one phone, read and write Characteristics, then disconnect, then another phone is able to connect with nRF Connect and do the same, etc., etc., back and forth, no problem.

Is there anything on the iOS/Android side of things when communicating with nRF52 devices that might account for this inability to connect sequentially?

RE: Trouble with non-concurrent multiple peers

Petter Myhre — Tue, 23 Jan 2018 09:35:39 GMT

As long as you are not advertising with a whitelist any device should be able to connect. Are you advertising with a whitelist? Is the second phone able to see the advertisements after you have disconnected?