Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52 SDK16 multi-link central does not reconnect to peripherals

Hi, I am developing a multi-link central using NRF52832 and SDK 16. I have implemented the scanning part and NRF_BLE_SCAN_SCAN_DURATION = 0. I am using address filter for scanning and it works as well.
When I power both central and peripheral, central connect with the peripheral.
When both are connected, if i remove power from central and re apply power, central connect with the peripheral.
When both are connected, if i remove power from peripheral and re apply power, central does not connect with the peripheral.

Any suggestions to fix the issue?
Thanks

Parents
  • Hello,

    Could you verify for me that the peripheral starts its advertising upon powering up again?
    Do you have a LED that is indicating that the peripheral is advertising, or could you use the nRF Sniffer tool to ensure that the advertisement is happening?
    What connection parameters have you set on your central? If you are using slave latency and a high connection interval it might take a while for the central to realize that the connection is broken.

    Looking forward to solving this issue together,

    Best regards,
    Karl

  • Hi,

    Thanks for your quick reply.

    Yes i checked. Peripheral is advertising. I have connected a J link debugger to the peripheral. And also I can connect to the peripheral using a mobile phone. 

    These are the scan parameters:

    ble_gap_scan_params_t g_scan_param = /**< Scan parameters requested for scanning and connection. */
    {
    .active = 0x01,
    .interval = 160,
    .window = 80,
    .filter_policy = BLE_GAP_SCAN_FP_ACCEPT_ALL,
    .timeout = 0
    .scan_phys = BLE_GAP_PHY_1MBPS,
    .extended = true,
    };

  • Hello,

    KasunR said:
    Thanks for your quick reply.

    No problem at all, I am happy to help!

    KasunR said:
    Yes i checked. Peripheral is advertising. I have connected a J link debugger to the peripheral. And also I can connect to the peripheral using a mobile phone. 

    I understand. Could you also verify for me that the central resumes scanning following a disconnect?
    Are you familiar with using the nRF Sniffer? I would be beneficial to see a sniffer trace of the two sequences you describe in your ticket: both connected, central loosing power and reconnecting and peripheral loosing power and resuming advertisement - without re-connection.

    KasunR said:
    These are the scan parameters:

    The scan parameters looks all right, thanks.

    Best regards,
    Karl

Reply
  • Hello,

    KasunR said:
    Thanks for your quick reply.

    No problem at all, I am happy to help!

    KasunR said:
    Yes i checked. Peripheral is advertising. I have connected a J link debugger to the peripheral. And also I can connect to the peripheral using a mobile phone. 

    I understand. Could you also verify for me that the central resumes scanning following a disconnect?
    Are you familiar with using the nRF Sniffer? I would be beneficial to see a sniffer trace of the two sequences you describe in your ticket: both connected, central loosing power and reconnecting and peripheral loosing power and resuming advertisement - without re-connection.

    KasunR said:
    These are the scan parameters:

    The scan parameters looks all right, thanks.

    Best regards,
    Karl

Children
  • OK i ll use a sniffer and send you a log. But it will require some time because I am not at office right now. I am using infinite scan time. Also I am using a address filter. Anyways I ll send a log as soon as i can.

  • KasunR said:
    OK i ll use a sniffer and send you a log.

    Great! This will help me better understand what is happening in your device's communication, and hopefully pinpoint the issue outright.
    For the logs, please make sure that the events are captured in the log; make sure that you have selected your device from the "Device" drop down menu. The picture below shows the default "all advertising devices" device option, and if you have chosen this the sniffer will not follow into the connection. So please choose your device from this menu.
     

    Furthermore, it would be good if you waited 2-3 seconds between each action you perform, i.e: power up devices, wait, connect, wait, power down peripheral, wait, power up peripheral, wait, reconnect, wait. Same for the other testing scenario.
    The log will contain thousands of packets, but this will provide a fuller picture.

    KasunR said:
    I am using infinite scan time. Also I am using a address filter.

    Yes, NRF_BLE_SCAN_SCAN_DURATION will make sure that your scanning does not time out - but it is still possible to stop the scanning manually.
    In most single-link central applications the scanning is manually stopped when a connection is made, and restarted upon disconnect / some other event.
    I would like you to verify that scanning is started again following a disconnect, in the event that it is stopped following a connection.

    Looking forward to resolving this issue together,

    Best regards,
    Karl

  • Hi, I called nrf_ble_scan_start inside BLE_GAP_EVT_DISCONNECTED and it worked. Now central connects with the peripheral. But why it stops scannig?

  • Hi,

    KasunR said:
    I called nrf_ble_scan_start inside BLE_GAP_EVT_DISCONNECTED and it worked. Now central connects with the peripheral.

    I am glad to hear that it resolved your issue!

    KasunR said:
    But why it stops scannig?

    I guess this might be configured in your ble_evt_handler as part of the _CONNECTED event.
    Could you check if scanning is stopped when a connection is established?

    Best regards,
    Karl 

  • I checked. I am not calling the api to stop scanning any where in the code. Does nrf library stops scanning once a connection been made? 

Related