NRFSDK5/SoftDevice - Context switching when using multiple different peripherals

[snoopy20]

Hi,

For supporting multiple different peripherals is it possible to get something back from a SoC observer which indicates the peripheral type?

https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.0.2/page/group_nrf_sdh_ble.html#ga78e6ffbd2e9d9b3e6805c30f3936ac86

Since all observers just get the context that was supplied (see below), and there's no means to target an observer for its specific type (uuid, service_handler etc), I'm puzzled on how to proceed.

NRF_SDH_BLE_OBSERVER(_name ## _obs, BLE_CSCS_BLE_OBSERVER_PRIO, ble_cscs_on_ble_evt, &_name)

[tesc]

Hi,

Might it be that the Scanning Module fills your needs?

I must admit I don't fully grasp what you are looking for. (E.g. are you scanning for the purpose of connecting, are you doing active scan (that is, with scan request and scan response), are you scanning for reading advertising data only, etc. Some elaboration there would make it easier for us to come with suggestions.)

Regards,
Terje

[snoopy20]

So I want to expose/export two different perpherials. Let's say CSCS and BPS

When the observer function gets called there is no means to find out which type of perpherial the event is for. All there is is the connection_handle and the context which we pre-supplied. 

SoftDevice doesn't know that the observer is for a particular perpherial type so it can't be filtering under-the-hood.

Maybe there's a some getPerpherialDetailsFromConnectionHandle type of call?

[snoopy20]

For context ultimately I'm trying to achieve a situation where I export and allow 1 instance of 1 of 2 different peripherals.

So using the above peripherals there can't be two BPS. I can't see how this is achieved either, it's like I need the means to disable the advertising of a particular peripheral type.

[tesc]

HI,

Right, so you connect to those two peripherals, then want to keep track of which is which?

The Database Discovery Module lets you discover what services are present on the device. Your application would be responsible for storing the connection handle.

We don't have CSCS or BPS clients in the nRF5 SDK, but there are some other client implementations such as e.g. for Heart Rate Service (<sdk_folder>\components\ble\ble_services\ble_hrs_c\). For those implementations, you will typically see a structure (e.g. ble_hrs_c_s) for the client, where the connection handle is stored in that structure, this way keeping track of which client instances are connected to which peers (and with which services.)

Regards,
Terje

[tesc]

Hi,

It is quite common for peripherals to advertise one or more BLE Services which it supports, in the advertisements. It is optional from the specification point of view, but if you are in control of the peripherals then that could be the way to decide already at advertisement which device is which.

It is technically possible to connect to multiple peripherals, with the same service, and keep those separate on the central. See the Multi-link Example.

Please note that the latest version of nRF5 SDK is v17.1.0. For new projects, however, we recommend the newer nRF Connect SDK, since the older nRF5 SDK is now in maintenance mode. I see this case is tagged with "production", and therefore assume the project is at a stage where it is too late to change SDK altogether, but at least you should consider an update to nRF5 SDK v17.1.0. For more on our SDKs, please see our nRF Connect SDK and nRF5 SDK statement.

Regards,
Terje