Understanding Multi peripheral concept | BLE

[SK]

Hi Everyone, 

I would like to understand how the multi peripheral application works in this given scenario: 

Scenario:

Considering one peripheral (P) is connected to 4-5 central devices (C1 - C5). All the central devices run the same copy of SW on them but are handled by different users at the same time. 

What i would like to know is how this peripheral will handle different requests from the central devices? I noticed that there is only one BLE handler in the multiperipheral application. How will that handle all the requests coming from these central devices? While all of them have the same characteristics. 

Example:

C1 sends a calibration request to P.

C2 sends an alert update to P.

C3 sends a connection request to P.

C4 is disconnected from P.

C5 sends calibration data to P after completing calibration. 

Will they be queued one after the other for processing by using QWR module? How will they be handled in the peripheral application? Distinguishing them by their MAC address maybe?

Even so, i did distinguish them using MAC addr, i can't run multiple copies of peripheral SW inside (doesn't make sense). 

So, if you guys can help me understand this multiperipheral concept, it would be of huge help !! 

Thank you. Stay safe, stay strong.

Best, 

-SK 

[Edvin]

Hello SK,

I don't know whether you have seen the example found in SDK\examples\ble_peripheral\experimental\ble_app_multiperipheral, which is an example that handles multiple connections as a peripheral.

 

How will that handle all the requests coming from these central devices? While all of them have the same characteristics. 

Example:

C1 sends a calibration request to P.

C2 sends an alert update to P.

C3 sends a connection request to P.

C4 is disconnected from P.

C5 sends calibration data to P after completing calibration. 

When you have several connections you need to monitor the connection handle of the events that you mention. Referring to the ble_app_multiperipheral example:

In main.c -> on_connected(), the line:

NRF_LOG_INFO("Connection with link 0x%x established.", p_gap_evt->conn_handle);

Will tell you what device that connected to that certain conn_handle. The conn_handle will not change until the device disconnects, but it may not be the same the next time the device connects.

If you want to know what device that connected, you can also fetch the BLE address using the event:

    NRF_LOG_INFO("Connected device addr: %02x:%02x:%02x:%02x:%02x:%02x", p_gap_evt->params.connected.peer_addr.addr[0],
                                                                        p_gap_evt->params.connected.peer_addr.addr[1],
                                                                        p_gap_evt->params.connected.peer_addr.addr[2],
                                                                        p_gap_evt->params.connected.peer_addr.addr[3],
                                                                        p_gap_evt->params.connected.peer_addr.addr[4],
                                                                        p_gap_evt->params.connected.peer_addr.addr[5]);

If you have some calibration data, I assume you will have a callback similar to led_write_handler() in this example. You can check what conn_handle that triggered the event from the line:

NRF_LOG_INFO("Received LED ON from link 0x%x!", conn_handle);

NB: The conn_handle is not always a direct parameter in the callback. It depends on how the callback events are set up. If you look in ble_lbs.c, you can see that the led_write_handler() is triggered from the line:

p_lbs->led_write_handler(p_ble_evt->evt.gap_evt.conn_handle, p_lbs, p_evt_write->data[0]);

All softdevice handlers have this p_ble_evt, so you can find the conn_handle using p_ble_evt->evt.gap_evt.conn_handle.

NB2: The function names I refer here are from SDK16.0.0, so if you use another version, some of the names may differ.

Best regards,

Edvin

[SK]

Thanks for your reply Edvin.

Edvin said:

When you have several connections you need to monitor the connection handle of the events that you mention.

To frame my question in a different way, how will it handle the requests when it is coming simultaneously from different users?

For example, C1 sends request to P to execute a task while P is already processing or executing that task for C2. Is there a way to handle this kind of scenario?

Edvin said:

The conn_handle is not always a direct parameter in the callback. It depends on how the callback events are set up. If you look in ble_lbs.c,

ble_lbs is a BLE service here. Similarly, service that i am using right now is BLE NUS. Now in its handler, i can have the code to differentiate requests from different users as u mentioned by using their connection handle or MAC address. But afterwards, to process that request, it will  loop back inside the main loop. Unless a queue mechanism is in place, i don't see it able to handle the simultaneous requests. Am i right in my assumption here? 

[Edvin]

SK said:

For example, C1 sends request to P to execute a task while P is already processing or executing that task for C2. Is there a way to handle this kind of scenario?

 BLE can't demand the perheral to execute tasks. That is up to your applications. What you see from the peripheral is events generated by the write to the characteristics, which holds the data written, and the connection handle. After that, it is up to your application what to do, and how to handle this.

Perhaps you need a queue system, as you describe, but that is up to your application.