One peripheral many centrals

RE: One peripheral many centrals

Petter Myhre — Fri, 01 Dec 2017 11:23:14 GMT

It is referenced by using p_context. For example inside ble_bas_on_ble_evt():

ble_bas_t * p_bas = (ble_bas_t *)p_context;

Does this answer your question?

RE: One peripheral many centrals

Roland — Wed, 29 Nov 2017 14:10:24 GMT

thanks for the advice. the state problem is what i am worried. but I will try on it.

Since defined in SDK, is #define NRF_SDH_BLE_OBSERVERS ( _name, _prio, _handler,_context, _cnt ) macro, actually implemented and supported? How should i refer to each instance of observers in code? Is there any example for guiding purpose?

RE: One peripheral many centrals

Petter Myhre — Tue, 28 Nov 2017 18:49:58 GMT

It sounds like you don't need one characteristic for each central, but it is difficult to say without more details. I guess as long as your procedures are stateless you should be good. I would give it a try first at least.

RE: One peripheral many centrals

Roland — Tue, 28 Nov 2017 09:49:43 GMT

these central devices connect to the peripheral at the same time. Each central device actually run the same copy of software, so their function and behavior are just the same, and the service/characteristic model defined are exactly the same. However, each central device may generate different data / status (for instance, they are operated by different users, or monitoring different area), which means different values/status for the same characteristic.

RE: One peripheral many centrals

Roland — Tue, 28 Nov 2017 09:42:17 GMT

I find this macro has been listed in SDK14:

#define NRF_SDH_BLE_OBSERVERS	(	 	_name,
 	_prio,
 	_handler,
 	_context,
 	_cnt 
)

But i am not sure if nordic services library already adopt this.

RE: One peripheral many centrals

Petter Myhre — Tue, 28 Nov 2017 09:29:49 GMT

When you say they have the same functions, but data exchanged is different, could you elaborate a bit? Will you only have one central device connected at the time?

RE: One peripheral many centrals

Roland — Tue, 28 Nov 2017 09:18:13 GMT

Sry for the late reply as i am working on other threads before turning back to this one.

Basically i have, say, 5 central devices that connect to the same peripheral device. each device has exactly same functions, but data exchanged with the peripheral device are different. One choice i have is to defined 5 services for each of them, or another one is have 1 service for them all. Having 5 services defined does not seem to be elegant or scalable solution. However having 1 for all will need to have multiple instance of characteristic/attribute values.

I saw your answer in this post said can have multiple instance of services defined. I would like to try this solution but in that case, i am not sure how multiple attribute instances are handled.

RE: One peripheral many centrals

Petter Myhre — Fri, 06 Oct 2017 12:12:28 GMT

I don't quite understand what you want to do, but by spec you can only have one server on a Bluetooth device:

There shall be only one instance of a server on each Bluetooth device; this implies that the attribute handles shall be identical for all supported bearers.

See Vol. 3, Part F, Section 2 in the Bluetooth core v5.0.

RE: One peripheral many centrals

endnode — Wed, 04 Oct 2017 12:55:18 GMT

I believe you are mixing terms and layers. Firstly there are Master And Slave roles on the lowest Logical Link layer. They are asymmetric and always peer to peer (as everything in Bluetooth) so you need o have right mix to establish the connection and you need to have right number of "slots" if you want to establish multiple links form single HW/SW stack (device). In BLE this is usually paired with the highest layer called Generic Access Profile (GAP) which simply says what roles each device plays and when. Master is called Central on GAP while Slave is called Peripheral. Anyway all this is (and I do agree it might be confusing at the beginning) logically independent with what is happening "in between" meaning on top of LL and bellow APP. That is called (G)ATT (ATTribute Protocol and Generic ATTribute protocol - technically two layers but no one is really picky about the boarder line because in 99% of cases it's GATT you see from the top), it has also asymmetric roles (called Server and Client) and you again need to have matching roles to make the data exchange happen but it's independent on LL (which runs bellow) and you can have both Client or Server on top of each Central and Peripheral. And you can have even both on top of any link established! (now it starts to be complex but that's the world around us;)

So finally to your question which doesn't make sense technically:

If you want to have multiple connections (links) from one device and you need them all be GAP Peripheral then you need to have BLE stack which supports this (optional) feature from BT SIG Core spec v4.2 (before only one GAP Peripheral role was specified for each device/stack instance). This is nRF52832 chip and S132 V5 (or S140 for nRF52840 once it will be available in production version). However on top of each of these links you need to make sure that you instantiate/initiate proper GATT Client or Server API in Nordic Soft Device (stack). Note that current limit of Nordic stack is 20 concurrent links (if RAM allows you to fulfill all functionality on top of each of them in APP layer = your application FW). You might also go with some open source stacks like Zephyr, they should support this use case as well.
If you just need to support certain GATT role then you can manage it (if you control both sides of the link so you can have matching asymmetric configuration;) on top of GAP Central link and up to 8 such Master links are supported by Nordic (and other stacks) already on nRF51.