Advertising/Scanning Problems

RE: Advertising/Scanning Problems

Milan — Mon, 02 May 2016 07:20:08 GMT

Hi petter,

what will happen if scan interval = 3.125ms scan window = 2.5ms advt interval = 20ms

I am trying to understand it more deeply. Your help will be appreciated.

RE: Advertising/Scanning Problems

Petter Myhre — Sun, 14 Jun 2015 14:47:21 GMT

Edit 17.06.2015, my previous clarification of the behavior was incorrect. Sorry. Please see below.

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?

advertising interval = advInt = 100ms random delay = ranDel = 0-10ms

You start with a scan of 200ms, after the scan window ends the scanner will try to schedule a timeslot for the next scan window, 400ms later.

The ~0ms advertising event is blocked, since a scan is ongoing. The advertiser will try to schedule a timeslot one advInt+ranDel later. It will be blocked again, then the advertiser will try to schedule a timeslot advInt+ranDel later, and it will succeed. When the advertising event ends the advertiser will try to schedule a timeslot for the next advertising event, advInt+ranDel after the start of the previous one. It will succeed. And so on.

There is a scan window scheduled to start at 600ms. So when the advertiser tries to schedule a timeslot inside it, it will be blocked. The advertiser will try to schedule a timeslot one advInt+ranDel later. If it is blocked it will try to schedule a timeslot one advInt+ranDel later. And so on.

I have just tried an advertising interval of 20 ms, scan window=scan interval=100ms, and scan before advertise with both s130_nrf51_1.0.0-3.alpha_softdevice.hex and s130_nrf51_1.0.0_softdevice.hex. They are both advertising and their behavior seem identical in the sniffer log.

RE: Advertising/Scanning Problems

Yaroslav — Thu, 04 Jun 2015 13:04:28 GMT

yes, I can but it looks unstable when changing order changes behavior.

RE: Advertising/Scanning Problems

Susheel Nuguru — Thu, 04 Jun 2015 12:59:04 GMT

Hi Yaroslav, Unfortunately this issue will take time to analyze as this is claimed to be related to scheduler. you said you can make it working by advertising first.

RE: Advertising/Scanning Problems

Yaroslav — Thu, 04 Jun 2015 10:08:19 GMT

Thank Aryan, do you have any news regarding the issue? This problem seriously affects our product so we must solve it very fast, as a result I would appreciate your feedback. If that is helpful - please tell me what exactly I should do to provide you an extra information which might help your team.

RE: Advertising/Scanning Problems

Susheel Nuguru — Mon, 01 Jun 2015 06:43:13 GMT

Yaroslav, I will bring your comments to engineer's notice. Thanks for your time.

/Susheel

RE: Advertising/Scanning Problems

Yaroslav — Sun, 31 May 2015 09:05:46 GMT

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!

RE: Advertising/Scanning Problems

Petter Myhre — Wed, 20 May 2015 13:54:02 GMT

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

RE: Advertising/Scanning Problems

Petter Myhre — Wed, 20 May 2015 13:53:56 GMT

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.

RE: Advertising/Scanning Problems

Yaroslav — Tue, 19 May 2015 17:55:21 GMT

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

RE: Advertising/Scanning Problems

Yaroslav — Tue, 19 May 2015 17:50:02 GMT

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?

RE: Advertising/Scanning Problems

Susheel Nuguru — Fri, 15 May 2015 08:14:47 GMT

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.
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)
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.

RE: Advertising/Scanning Problems

Yaroslav — Mon, 11 May 2015 18:59:25 GMT

Of course, device using one antenna and radio module can't transmit and receive at the same time. But I was sure that nRF can switch to advertising during scan window. My investigations shows me that nRF doesn't transmit data during scan window at all.
I understand this behavior but again question #1.
Yes, but it is not reproducible on S130_1.0.0.3 Alfa, but it is on S130_1.0.0 recently released

RE: Advertising/Scanning Problems

Susheel Nuguru — Mon, 11 May 2015 14:47:54 GMT

The device cannot scan and advertise at the same time, but they are multiplexed over the timeline.

2)when you reset boards at different time, then scanner and advertiser on each boards start at different time. So the scanner on one board can see the advertiser on the other. This has also happened due to many factor, like how far did you reset these boards, scan interval and advertising interval.