Advertising/Scanning Problems

[Yaroslav]

Issue is similar to devzone.nordicsemi.com/.../

I'm developing an application based on latest SoftDevice 130_1.0.0 and using two or more DevKits. My application starts advertising and scanning simultaneously with parameters:

	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    = BLE_GAP_ADV_INTERVAL_MIN;
	adv_params.timeout     = BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED;

	if(adv_mode == LIGO_ADVERT_MODE_CONNECTED)
	{		
		adv_params.type		= BLE_GAP_ADV_TYPE_ADV_NONCONN_IND;
		adv_params.interval	= BLE_GAP_ADV_NONCON_INTERVAL_MIN;
	}

	scan_param.active = 0;
    scan_param.selective = 0;
    scan_param.p_whitelist = NULL;
    scan_param.timeout = 0;
    scan_param.interval = 0x03C0;		// 600 ms
    scan_param.window = 0x0140;		// 200 ms

Each board using LED indicates receiving advertise reports.

So, I've noticed next:

1. When I reset(or power on) two board at the same time - both boards don't indicate anything, it means there are no incoming advertising packets. Seems, nRF during scan doesn't advertise.

2. When I reset(or power on) two board at different time - they both work fine but after some time (adout 15-30 min) I see that advertising's appear much rarely up to total stopping receiving adv packets for few minutes and then I see advertise packets again.

3. When I set next scan interval = window, like:

   scan_param.interval = 0x03C0; // 600 ms scan_param.window = 0x03C0; // 600 ms I don't see any advertising using nRF MasterControlPanel for PC and/or for smartphone. Also both boards don't indicate anything.

4. When I start a app_timer() in advertising report handler I notice that scanning activity becomes worst - I can see indications very rare.

So, could you explain this behavior?

[Susheel Nuguru]

1. The adv intervals have random delay added internally, but scan intervals do not have this random delay. if two scanner/adv device are start at same time, both will scan or adv at the sametime, hence you will not see any adv reports. eventually, adv will overlap over its device scan window and if lucky 'other' device adv shouldn't overlap its scanner, then the 'other' device will get adv report. We are talking about a very small random delay added to adv on each side and over time we see that these two gets placed far enough to see each other adv data.

2. that is also expected.... when adv role overlaps scan role, it round robins, its all random here, there will be periods of low adv rate, and periods of normal adv rate. The low rate is dependent on scan window and adv interval. if adv interval is smaller than scan window, many adv will be missing. It is always adviced to use lowest scan interval and scan window when you require continous scanning so that other roles can get chance early (not be displace by large scan window size)

3. I am told that nothing in scheduling in this scenario has changed between two releases you mentioned. It could be a coincidence. Can you observe this in MCP with continuous scanning and see if you are really missing adv packets completely.

[Yaroslav]

2. Could you clarify behavior at the next timings:

• adv interval: 100mS
• scan window: 200mS
• scan interval: 600mS

Let assume that scan starts first, then: 0-200ms scanning

~200 adv

~300 adv

~400 adv

~500 adv

~600 adv

800-100 scanning

and so on...

So, is in correct?