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?

[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

[snoopy20]

I'll take a look at the DDM. I also hoped something might be on the GAP event (&p_ble_evt->evt.gap_evt.params) but to no avail. For read/writes it is possible to reference by characteristic handle (ble_gatts_evt_write_t const *p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;)

All the examples I've seen so far and I imagine the DDM will be the same are for when you have multiple connection instantances of the same perpherial. In this case it's just a case of keeping a list of the connection_handles and no differentiation in code is needed, since all perpherials are the same.

The problem starts when they are different because so far I've found no means to detect this.

I'm on v17.1.0 but was referencing an old folder for examples.

[snoopy20]

DDM not relevant. Let me try again...

I register an observer. Let's take the cscs module. BLE_CSCS_DEF(m_cscs);

When a connected event fires how do I determine that the event is for a cscs and not a different type of peripheral?

[snoopy20]

I think I know where I'm going wrong.

I was thinking that by setting up two services would be two connections, which it isn't. So something connects and it gets both services, ignoring what it isn't interested in.

The reason for my misunderstanding is generally for most examples the connection_handle is stored on the context (well config) struct for a given peripheral, which is fine for a single connection but still technically wrong.