A question about the part that detects disconnection in the standby state of ble_peripheral and central

RE: A question about the part that detects disconnection in the standby state of ble_peripheral and central

Hieu — Fri, 26 May 2023 08:10:15 GMT

Hi pkr2258,

[quote user="pkr2258"]Did you have a good vacation?[/quote]

I had a relaxing time. Thank you for asking 🙂.

[quote user="pkr2258"]- When the central and peripherals are connected, we are going to use the function of checking the connection status while transmitting and receiving periodically.[/quote]

I am not certain what function you plan to use to check the status of the connection. In the nRF5 SDK, the connection status is managed by the SoftDevice. The SoftDevice informed the application of changes in connection by sending events to the application's SoftDevice Handler. Two key events that help you monitor a connection are BLE_GAP_EVT_CONNECTED and BLE_GAP_EVT_DISCONNECTED.

[quote user="pkr2258"]- It is understood as checking the connection status at the time period defined in #deine below.[/quote]

As explained above, the SoftDevice is in charge of monitoring the connection.

Those defines are used in used in sd_ble_gap_ppcp_set() as Connection Intervals parameter. They could be indicator of how often the "connection status" is checked, because peers in a connection only check with each other in Connection Events, which are 1x Connection Interval apart.

However, sd_ble_gap_ppcp_set() only sets the preferred Connection Interval of the Peripheral.
It is not guaranteed the Connection Interval of the connection. The Central device has the final decision about it.

To get the Connection Interval of an active connection, you need to get it from the parameters of the gap events BLE_GAP_EVT_CONNECTED and .

[quote user="pkr2258"]2.1 Set TX Power as "BLE_GAP_TX_POWER_ROLE_ADV" when trying to register. ( Implemented successfully so far )
-> sd_ble_gap_tx_power_set (BLE_GAP_TX_POWER_ROLE_ADV, m_advertising.adv_handle, TX_POWER_LEVEL)[/quote]

This seems correct. However, if I remember correctly, multiple Advertising Sets are not yet implemented in the nRF5 SDK, so please note that you only have one advertising set.

[quote user="pkr2258"]2.2 When registration is completed, try to lower the receiving sensitivity with "BLE_GAP_TX_POWER_ROLE_CONN".
I can't find which handler to connect to the sd_ble_gap_tx_power_set() function.
Which handler should be used?

-> sd_ble_gap_tx_power_set
(BLE_GAP_TX_POWER_ROLE_CONN, any handler here?, TX_POWER_LEVEL);[/quote]

The handle of a connection is given as part of the BLE_GAP_EVT_CONNECTED event in ble_evt_t.gap_evt.conn_handle.

[quote user="pkr2258"]

2.3 When registration is completed and the connection status of central and peripheral is checked at a specific interval,
If the status check fails, we are going to implement something that raises the TX Power.

So, I would like to know the part where the connection is checked, not the part where the connection is completely disconnected.
In which function will it be performed?

[/quote]

I finally see your point here. However, I am afraid the SoftDevice does not give such timing event.

Technically, you can register Radio Notifications like I explained in this DevZone question: callback before the BLE event. However, please note that the Radio Notifications add processing burden onto the SoftDevice and may affect performance, and there are caveats as I explained in that DevZone question.

Knowing when the check happen also does not help you catch the disconnection before it happens, because everything is handled in the SoftDevice.

For your purpose, perhaps you are more interested in RSSI monitoring. Please look up the keyword "rssi" in the SoftDevice BLE GAP function documentation.

Regards,

Hieu

RE: A question about the part that detects disconnection in the standby state of ble_peripheral and central

pkr2258 — Fri, 26 May 2023 01:23:55 GMT

hi,

Did you have a good vacation?

I couldn't write the question in detail. A bit more detailed...

1. When central and peripheral are connected, basic connection status check

- When the central and peripherals are connected, we are going to use the function of checking the connection status while transmitting and receiving periodically.

- It is understood as checking the connection status at the time period defined in #deine below.

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(75, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */

2. TX Power roles

2.1 Set TX Power as "BLE_GAP_TX_POWER_ROLE_ADV" when trying to register. ( Implemented successfully so far )
-> sd_ble_gap_tx_power_set (BLE_GAP_TX_POWER_ROLE_ADV, m_advertising.adv_handle, TX_POWER_LEVEL)

2.2 When registration is completed, try to lower the receiving sensitivity with "BLE_GAP_TX_POWER_ROLE_CONN".
I can't find which handler to connect to the sd_ble_gap_tx_power_set() function.
Which handler should be used?

-> sd_ble_gap_tx_power_set
(BLE_GAP_TX_POWER_ROLE_CONN, any handler here?, TX_POWER_LEVEL);

2.3 When registration is completed and the connection status of central and peripheral is checked at a specific interval,
If the status check fails, we are going to implement something that raises the TX Power.

So, I would like to know the part where the connection is checked, not the part where the connection is completely disconnected.
In which function will it be performed?

/**@brief GAP TX Power roles.
 */
enum BLE_GAP_TX_POWER_ROLES
{
  BLE_GAP_TX_POWER_ROLE_ADV       = 1,           /**< Advertiser role. */
  BLE_GAP_TX_POWER_ROLE_CONN      = 3,           /**< Connection role. */
};

thank.

RE: A question about the part that detects disconnection in the standby state of ble_peripheral and central

Hieu — Tue, 16 May 2023 20:09:03 GMT

Hi pkr2258,

In the nRF5 SDK, the SoftDevice sends events to the application, including ones concerning the connection. The auto restart of scanning and advertising is done by handling of the event BLE_GAP_EVT_DISCONNECTED.

In the ble_app_uart_c central example, the NUS Client module handles BLE_GAP_EVT_DISCONNECTED, and sends a BLE_NUS_C_EVT_DISCONNECTED event to the application. The application then handles this event and restart scanning in main.c

ble_nus_c.c

void ble_nus_c_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
{
    ble_nus_c_t * p_ble_nus_c = (ble_nus_c_t *)p_context;

    ...

    switch (p_ble_evt->header.evt_id)
    {
        ...

        case BLE_GAP_EVT_DISCONNECTED:
            if (p_ble_evt->evt.gap_evt.conn_handle == p_ble_nus_c->conn_handle
                    && p_ble_nus_c->evt_handler != NULL)
            {
                ble_nus_c_evt_t nus_c_evt;

                nus_c_evt.evt_type = BLE_NUS_C_EVT_DISCONNECTED;

                p_ble_nus_c->conn_handle = BLE_CONN_HANDLE_INVALID;
                p_ble_nus_c->evt_handler(p_ble_nus_c, &nus_c_evt);
            }
            break;

        default:
            // No implementation needed.
            break;
    }
}

main.c

/**@brief Callback handling Nordic UART Service (NUS) client events.
 *
 * @details This function is called to notify the application of NUS client events.
 *
 * @param[in]   p_ble_nus_c   NUS client handle. This identifies the NUS client.
 * @param[in]   p_ble_nus_evt Pointer to the NUS client event.
 */

/**@snippet [Handling events from the ble_nus_c module] */
static void ble_nus_c_evt_handler(ble_nus_c_t * p_ble_nus_c, ble_nus_c_evt_t const * p_ble_nus_evt)
{
    ret_code_t err_code;

    switch (p_ble_nus_evt->evt_type)
    {
        ...

        case BLE_NUS_C_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected.");
            scan_start();
            break;
    }
}

In the ble_app_uart peripheral example, the advertising is restarted by the Advertising Module in ble_advertising.c

/**@brief Function for handling the Disconnected event.
 *
 * @param[in] p_advertising Advertising module instance.
 * @param[in] p_ble_evt Event received from the BLE stack.
 */
static void on_disconnected(ble_advertising_t * const p_advertising, ble_evt_t const * p_ble_evt)
{
    uint32_t ret;

    p_advertising->whitelist_temporarily_disabled = false;

    if (p_ble_evt->evt.gap_evt.conn_handle == p_advertising->current_slave_link_conn_handle &&
        p_advertising->adv_modes_config.ble_adv_on_disconnect_disabled == false)
    {
       ret = ble_advertising_start(p_advertising, BLE_ADV_MODE_DIRECTED_HIGH_DUTY);
       if ((ret != NRF_SUCCESS) && (p_advertising->error_handler != NULL))
       {
           p_advertising->error_handler(ret);
       }
    }
}

void ble_advertising_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
{
    ble_advertising_t * p_advertising = (ble_advertising_t *)p_context;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            on_connected(p_advertising, p_ble_evt);
            break;

        // Upon disconnection, whitelist will be activated and direct advertising is started.
        case BLE_GAP_EVT_DISCONNECTED:
            on_disconnected(p_advertising, p_ble_evt);
            break;

        // Upon terminated advertising (time-out), the next advertising mode is started.
        case BLE_GAP_EVT_ADV_SET_TERMINATED:
            on_terminated(p_advertising, p_ble_evt);
            break;

        default:
            break;
    }
}

Please be informed that I will have a holiday and days off from tomorrow. I will return later next week and continue to support you if you have any further questions. My apology for the inconvenience.

Regards,

Hieu