What is the best strategy for connection between specific central and peripheral when both are powered up and then locking the connection so no more devices interfere?
What is the best strategy for connection between specific central and peripheral when both are powered up and then locking the connection so no more devices interfere?
Hi.
Maybe you could elaborate a little bit on your usecase here?
But after you connect to your preferred device, you don't have to start scanning for more devices. You can choose only to allow 1 connection. You can add your device to a whitelist etc.
If you share some more information about your application or requirements, we can discuss further what could be the best way for you to solve this.
Br,
Joakim
Thank you, Joakim.
Currently, we want to hardcore (in the firmware as configuration both in the peripheral and central devices) that peripheral P will connect only to Central C1, Central C2, and Central C3 (C2 and/or C3 may be not present in some cases). We do not want any interaction by the user (pressing the button, waiting for pairing), just when peripheral P and Central C1 are powered up, they establish a connection, and no more connections (except C2 and C3 if powered up) are allowed.
I assume this is possible if the peripheral serves as a beacon, right? How to select (filter) data coming from a specific beacon then? Also assuring the "freshnes" of the data received from the beacon can be a challenge.
Or do we need to switch the option - one Central device and three peripherals?
Thanks. Is this also mean that one peripheral can establish a connection with two or more central simultaneously?
Yes, that is possible.
We have the BLE Multiperipheral sample in the SDK that demonstrates how one Peripheral can connect to several Centrals.
_____________
Br,
Joakim
Thanks all clear. By the way it is interesting that multi peripheral example is called experimental :)
StanislavDimitrov said:By the way it is interesting that multi peripheral example is called experimenta
As Simon wrote in this previous ticket:
The experimental libraries have undergone less testing, and have usually been out for a shorter amount of time, so the chance of discovering bugs will be larger although none of the libraries should be assumed to be completely free of bugs.
All libraries and examples in the SDK, both experimental and not, are provided "as is", so in the end, it is up to you to test your application sufficiently and confirm that it meets your requirements.
Also, as the nRF5 SDK is in maintenance mode, support for new features beyond Bluetooth LE 5 will not be added to the nRF5 SDK. For instance, Bluetooth Direction Finding, Bluetooth LE Audio, and so forth are not supported and will not be supported in the nRF5 SDK.
I would suggest looking at the nRF Connect SDK.
Br,
Joakim
If you have any further questions, please let me know.
You are also welcome to open a new ticket if you have any more questions in the future.
Br,
Joakim