A phenomenon in which NUS's Central stops midway while performing a BLE scan.

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

David_Kim — Thu, 25 Apr 2024 06:54:42 GMT

Something somewhat strange happened.

I created a new and improved PCB, and the above problem disappeared.

What was improved

- Modify the load capacitor value of the 32.768kHz crystal in the peripheral (refer to the formula)

- Fixed 2-pin GND disconnection among 4 pins of peripheral and central 32Mhz Crystal
- Change peripheral CONN_INTERVAL related parameters

[ after ]

#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. */
#define SLAVE_LATENCY 0 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */

[ Before ]

//#define MIN_CONN_INTERVAL MSEC_TO_UNITS(400, UNIT_1_25_MS) /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
//#define MAX_CONN_INTERVAL MSEC_TO_UNITS(500, UNIT_1_25_MS) /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */
//#define SLAVE_LATENCY 5 /**< Slave latency. */
//#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(10000, UNIT_10_MS) /**< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

Simonr — Mon, 22 Jan 2024 14:29:16 GMT

I just ran the basic samples on two nRF52832 DKs on my end to try and reproduce this, but I'm not able to, as the central that doesn't get connected to simply disconnects with a 0x3E(CONN_FAILED_TO_BE_ESTABLISHED) or 0x08 (CONN_TIMEOUT) and then starts scanning again on its own. Here is some logging on my end. The peripheral I'm trying to connect to is target EE88A50528C2. Please excuse the other device that it tries connecting to, but there are multiple devices in range here at our office causing this.

It was never necessary resetting either of the DKs to make them start scanning after "not being the chosen one", and this was done without any changes to the Nordic UART service central/peripheral example projects in nRF5 SDK v17.1.0. Have you made any changes to the projects on your end that might have trigged this to become an issue? For example some check of the connection state of the central no longer being checked or similar?

Best regards,

Simon

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

David_Kim — Sun, 21 Jan 2024 23:04:41 GMT

I am already using nRF5_SDK_17.1.0 version.

thank

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

Simonr — Fri, 19 Jan 2024 09:54:19 GMT

I understand, can you share what exact SDK version you're working on? If you're not on nRF5 SDK v17.1.0 already I'd recommend upgrading to that. We'll try to reproduce and review this on our side as well and get back to you.

Best regards,

Simon

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

David_Kim — Thu, 18 Jan 2024 00:55:51 GMT

hi,

My reply was late because I had to take care of other work first. Please understand.

[quote userid="75734" url="~/f/nordic-q-a/105102/a-phenomenon-in-which-nus-s-central-stops-midway-while-performing-a-ble-scan/453342"]I'm struggling a bit to understand you here. Does the basic NUS sample also result in the same behavior that if two centrals with the NUS sample tries to connect to the same peripheral, one will connect while the other will just be stuck trying to connect forever and not restart scanning? And how long are you waiting without seeing any response from the central device that didn't connect?[/quote]

As you said, I conducted the following experiment on the nRF52-DK board to check the operation status of the basic NUS.

1) Prepare two nRF52-DK boards set to Central and start scanning.

2) Prepare one nRF52-DK board set to Peripheral and start advertising.

3) Check debugging messages through serial port

As you can see in the window below,

The periphral was connected to the left cental.

Looking at the MAC to the right central, it appears that an attempt was made to connect periphreal.

In other words, the condition of attempting to connect one peripheral to two centrals, which was the problem, was reproduced.

-> Central, which has failed to connect, stops in the connecting state and does not start scanning again.

In this state, I turned off the peripheral power,

- The normally connected Central started scanning again.

- Central, which failed and stopped during connection, does not start scanning again.

If Periphal, which was connecting, starts advertising again... the connection is completed and the following operations proceed normally.

Looking at the results above

While connecting to a periphreal, the failed central appears to be still waiting for that periphral.

We need improvement in this area.

This is because we are working on products that frequently require multiple centrals to be installed.

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

Simonr — Tue, 31 Oct 2023 15:33:33 GMT

I'm struggling a bit to understand you here. Does the basic NUS sample also result in the same behavior that if two centrals with the NUS sample tries to connect to the same peripheral, one will connect while the other will just be stuck trying to connect forever and not restart scanning? And how long are you waiting without seeing any response from the central device that didn't connect?

What are the conn_params; set to in your application? There should be a connection timeout I think that eventually times out if the peripheral doesn't respond, and then the scanner will restart when it gets out of the connection function.

Best regards,

Simon

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

David_Kim — Mon, 30 Oct 2023 13:36:47 GMT

hi, Simonr

I analyzed the part you provided.

As you said, the function static void scan_evt_handler(scan_evt_t const * p_scan_evt) has TIMEOUT.

However, as you can see from the debugging message above, TIMEOUT was not executed.

So, I looked at the basic NUS example again and there is no difference.

case NRF_BLE_SCAN_EVT_SCAN_TIMEOUT:

{

printf("Scan timed out\n\r");

scan_start();

} break;

static void scan_evt_handler(scan_evt_t const * p_scan_evt)
{
    int8_t rssi;
    ret_code_t err_code;
    //ble_gap_evt_adv_report_t const *p_adv_report      = &p_scan_evt->params.p_whitelist_adv_report;

    switch(p_scan_evt->scan_evt_id)
    {
         case NRF_BLE_SCAN_EVT_CONNECTING_ERROR:
         {
              err_code = p_scan_evt->params.connecting_err.err_code;
              APP_ERROR_CHECK(err_code);
              printf("case NRF_BLE_SCAN_EVT_CONNECTING_ERROR\n\r");

         } break;

         case NRF_BLE_SCAN_EVT_CONNECTED:
         {
             rssi = p_scan_evt->params.p_whitelist_adv_report->rssi;

            ble_gap_evt_connected_t const * p_connected =
                               p_scan_evt->params.connected.p_connected;
             // Scan is automatically stopped by the connection.
             
           
            printf("\n\r> Connecting %02x %02x %02x %02x %02x %02x  %ddBm\n\r",
                p_connected->peer_addr.addr[0],
                p_connected->peer_addr.addr[1],
                p_connected->peer_addr.addr[2],
                p_connected->peer_addr.addr[3],
                p_connected->peer_addr.addr[4],
                p_connected->peer_addr.addr[5],
                 rssi
            );
           
             
           
             /*
             NRF_LOG_INFO("Connecting to target %02x%02x%02x%02x%02x%02x",
                      p_connected->peer_addr.addr[0],
                      p_connected->peer_addr.addr[1],
                      p_connected->peer_addr.addr[2],
                      p_connected->peer_addr.addr[3],
                      p_connected->peer_addr.addr[4],
                      p_connected->peer_addr.addr[5]
                      );
           
            */
 

         } break;

         case NRF_BLE_SCAN_EVT_SCAN_TIMEOUT:
         {
             printf("Scan timed out\n\r");
             scan_start();
         } break;

         default:
             break;
    }
}

And I looked at the nrf_ble_scan_connect_with_target() function where the actual connection is made.
nrf_ble_scan_stop(), which again stops scanning; There is a function.

Likewise, there seems to be no problematic differences from the basic NUS source.

static void nrf_ble_scan_connect_with_target(nrf_ble_scan_t           const * const p_scan_ctx,
                                             ble_gap_evt_adv_report_t const * const p_adv_report)
{
    ret_code_t err_code;
    scan_evt_t scan_evt;

     int8_t rssi;

    // For readability.
    ble_gap_addr_t const        * p_addr        = &p_adv_report->peer_addr;
    ble_gap_scan_params_t const * p_scan_params = &p_scan_ctx->scan_params;
    ble_gap_conn_params_t const * p_conn_params = &p_scan_ctx->conn_params;
    uint8_t                       con_cfg_tag   = p_scan_ctx->conn_cfg_tag;


    rssi = p_adv_report->rssi;
    printf("> ble_scan RSSI Filter: %ddBm", rssi);
    if( rssi < gRSSI_Filter_mode )
    {
        printf(" ble_scan_connect_with_target - RSSI Filter fail\n\r");
        return;
    }
   

    // Return if the automatic connection is disabled.
    if (!p_scan_ctx->connect_if_match)
    {
        return;
    }

    // Stop scanning.
    nrf_ble_scan_stop();

    memset(&scan_evt, 0, sizeof(scan_evt));

    // Establish connection.
    err_code = sd_ble_gap_connect(p_addr,
                                  p_scan_params,
                                  p_conn_params,
                                  con_cfg_tag);

    printf("> ble_scan_connect Connecting\n\r");

    scan_evt.scan_evt_id                    = NRF_BLE_SCAN_EVT_CONNECTING_ERROR;
    scan_evt.params.connecting_err.err_code = err_code;

    printf("> ble_scan Connection status: %d\n\r", err_code);

    // If an error occurred, send an event to the event handler.
    if ((err_code != NRF_SUCCESS) && (p_scan_ctx->evt_handler != NULL))
    {
        p_scan_ctx->evt_handler(&scan_evt);
    }

}

The conclusive problem is that case NRF_BLE_SCAN_EVT_SCAN_TIMEOUT: does not occur.
Why is that so? I can't find the difference.

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

Simonr — Mon, 30 Oct 2023 12:50:37 GMT

From the bottom screenshot you provided it seems like both central tries to connect to the peripheral at the same time, as ble_scan_connect Connecting is printed on both sides. If so it makes sense that both devices stops scanning and tries to connect, however only one of them will be able to and then it depends how the central handles a connection procedure that doesn't end up connecting.

In the default NUS example project in the nRF5 SDK, the scan_evt_handler handles scan events, where scanning is stopped when it gets a connection event, but it also has a timeout event that's triggered and restarts scanning if it times out, but you seem to be using a custom ble_scan_connect() function from what I can tell, so maybe it doesn't handle a timeout?

Best regards,

Simon

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

David_Kim — Sat, 28 Oct 2023 15:00:44 GMT

hi, Simonr

[quote userid="75734" url="~/f/nordic-q-a/105102/a-phenomenon-in-which-nus-s-central-stops-midway-while-performing-a-ble-scan/452789"]This sounds like it might be a misunderstanding. When you connect to one central with the peripheral, that peripheral will naturally stop advertising. So if it is the only advertising device your other central is scanning for it might seem like it stops scanning, or have you debugged and specifically see that the radio or scan function stops once the peripheral is connected to the other central?[/quote]

I am connecting two peripheral devices to the PC and checking the debugging messages.

And when you turn on pheipheal, the above phenomenon occurs.

As you can see in the captured image below, Central in the left terminal program and Central in the right terminal program

are running simultaneously.

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context) -> BLE_GAP_EVT_ADV_REPORT

When the two centrals are scanning as shown in the captured image above, when the peripheral is turned on, it looks like the image below.

( Name filter )

The left central stopped scanning and the right central connected normally.

What makes me think that the left central has stopped scanning is that debugging messages for scans no longer appear.

Additionally, even if the peripheral device is turned on, it does not connect.

Isn't it possible that the scan stops during the connection process and there is no time-out function for failure?

RE: A phenomenon in which NUS's Central stops midway while performing a BLE scan.

Simonr — Fri, 27 Oct 2023 12:56:58 GMT

This sounds like it might be a misunderstanding. When you connect to one central with the peripheral, that peripheral will naturally stop advertising. So if it is the only advertising device your other central is scanning for it might seem like it stops scanning, or have you debugged and specifically see that the radio or scan function stops once the peripheral is connected to the other central?

To make sure it isn't the case that you're only seeing the one peripheral stops advertising you can have two devices advertising that the central will detect. Either another DK running the BLE NUS peripheral sample, or a phone with the nRF Connect app advertising with the Nordic UART Service.

Best regards,

Simon