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

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?
Parents
  • Hi

    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

Reply
  • Hi

    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

Children
  • hi,

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

    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.

Related