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?

[Yaroslav]

These all things happen during connection. Does connection have some affect on adv or scan? I didn't notice such behavior during disconnected state.

[Petter Myhre]

If you have a scan interval of 600 ms the second scan window will start at 600 ms timestamp, except if there is an advertising event is on going at that time. Then it will start after that event. Then the next scan window will start 600 ms after the start of the previous scan window(if there is no advertising event happening at that time).

It's a little bit different if you are in a connection, the connection event needs to be handled at specific times (connection interval). It can't be shifted. The connection events have lower priority than scaning and advertising so it will be dropped instead. However, the connection event closest to the connection supervision timeout will get the highest priority and won't be dropped.

[Petter Myhre]

I also want to mention that the advertising interval is not exactly 100ms, please see this.

[Yaroslav]

Regarding to "3) I am told that nothing in scheduling in this scenario has changed between two releases you mentioned..."

• I still believe that something was changed. My app that successfully works on previous SD versions but doesn't on latest S130_1.0. I mean that app doesn't advertise at:

  • Non-connected state

  • adv interwal is 20mS

  • scan window = scan interval = 100ms

  • app starts scan before advertise.

I repeat again that this scheme works fine on older SD and it was not some short tries but I used my app for months.

Now I can make it working when switch starting scan with adv - meaning starting adv before scan. anyway I can say that something still was changed in scheduler. Thanks!