Understanding Multi peripheral concept | BLE

RE: Understanding Multi peripheral concept | BLE

Edvin — Mon, 20 Apr 2020 07:10:43 GMT

[quote user="Samarth"]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?[/quote]

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.

RE: Understanding Multi peripheral concept | BLE

SK — Mon, 20 Apr 2020 02:32:16 GMT

Thanks for your reply Edvin.

[quote userid="26071" url="~/f/nordic-q-a/60240/understanding-multi-peripheral-concept-ble/245184"]When you have several connections you need to monitor the connection handle of the events that you mention.[/quote]

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?

[quote userid="26071" url="~/f/nordic-q-a/60240/understanding-multi-peripheral-concept-ble/245184"]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,[/quote]

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?

RE: Understanding Multi peripheral concept | BLE

Edvin — Fri, 17 Apr 2020 09:55:39 GMT

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.

[quote user=""][/quote]

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