Problem with slow advertising nRF51 SDK9

[Mikhail]

I use SDK 9 and nrF51 in the advertising mode. I want to advertise each 1s packets. First, I call function

set_adv_params(&m_adv_params);

where I

static void set_adv_params(ble_gap_adv_params_t * adv_params)

{ memset(adv_params, 0, sizeof(ble_gap_adv_params_t));

adv_params->type        	= BLE_GAP_ADV_TYPE_ADV_IND;
adv_params->p_peer_addr 	= NULL;
adv_params->fp          	= BLE_GAP_ADV_FP_ANY;
adv_params->interval	    = 1600;
adv_params->timeout     	= 180;

}

Than

sd_ble_gap_adv_start(&m_adv_params);

It is work. But I see very strange behavior. When I insert battery in my deevice, after few time I see that adv packet send and central received it. Repeat, first start and advertise is fast. When I out of range from ble device, central loss adv packet and disconnect it. After that I again close peripherial to central and central again received adv packets but with some delay (5-8 seconds). I mean same program started on the peripherial without reset. What reason of this strange behavior?

[Jørn]

Hello Mikhail

I suspect the reason you see such varying delays before your central detects your peripheral is due an unlucky choice of advertising interval and scan interval/window.

Your peripheral only advertises once every second, during which time it advertises sequentially on all three advertisement channels. The duration of this broadcast is very short.

Your central is configured with a scan window and interval, and will look for the peripheral once per scan interval, for the time specified by the scan window, and in only one channel at a time. With a long advertisement interval as you have the central and peripheral intervals might "miss" one another, so that the peripheral isn't advertising when the central is looking for it.

Please see section A in this blog post for more details on how central and peripheral behaves during advertisement devzone.nordicsemi.com/.../

You could try to change your peripherals advertisement interval, or the central's scan interval and window, to see if you get a more predictable result.

Best regards

Jørn Frøysa

[Jørn]

Hi! The exact way to do it will depend on what your central is and how it keeps track of its peers. If it is a Nordic device you can look at the multilink central example in the SDK, and see what they do on connection events. In SDK12, on disconnect, they perform a check very similar to yours to see if there are any devices connected with the following line

if (central_link_cnt == 0)
{
 bsp_board_led_off(CENTRAL_CONNECTED_LED);
}

In SDK 9 they use a similar check for m_peer_count, and then decrement it upon disconnect. So I believe your check is a viable way to doing it, as long as m_peer_list.length contains an updated number of currently connected peers.