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

[David_Kim]

hello.

I have two NUS Centrals running at the same time. BLE Scan continues to run during standby.

static void scan_start(void)
{
    ret_code_t ret;

    printf("> Scanstart ");
    ret = nrf_ble_scan_start(&m_scan);
    APP_ERROR_CHECK(ret);

    Bsp_led_indication_Scanning_clr();
    ret = bsp_indication_set(BSP_INDICATE_SCANNING); // connection LED
    APP_ERROR_CHECK(ret);

}

The problem is that when the peripheral PCB is turned on while the two Centrals are performing BLE Scan,
One connection is made to the Central, and the other one stops while scanning.

There is no problem with other operations, only the BLE Scan stops.

Why is this like this?

Also, is there a way to check whether BLE SCAN is operating and restart it if BLE SCAN is stopped?

[David_Kim]

hi,

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

Simonr said:

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?

.

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.

[Simonr]

Hi

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

[David_Kim]

HI

I am already using nRF5_SDK_17.1.0 version.

thank

[Simonr]

Hi

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

[David_Kim]

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. */