NRF52 SDK16 multi-link central does not reconnect to peripherals

[KasunR]

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

[Karl Ylvisaker]

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

[KasunR]

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,
};

[Karl Ylvisaker]

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

[KasunR]

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.

[Karl Ylvisaker]

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