How to improve Social Distance scanning performance?

[Jebakumar]

We are adding social distance feature to our existing product. We are facing performance issue. The device has one peripheral role and one observer role. I have set scanning interval to 100ms and scanning window to 50ms. Advertising interval set to 25ms. The situation is that, we are testing the scanning performance by resetting the device every time.

We scan to only our intended device. 

3 out of 5 times, the device is able to scan the intended device well. say 5 to 10 scanning occurrence of the intended device happened in every second.

but 2 out of 5 times, the scanning performance is not so good. It means, it is not able to scan the intended device well enough. the number of scanning occurrence of the intended device in these times are one or zero for every second. If we reset the intended device in this situation, then the number of scanning occurrence of the intended device is increased.

Even if we place the devices very close (5cm) to each other, the scanning performance result is same.

How we can improve the scanning performance all the times.

What is the best scanning interval, scanning window and advertising interval when the device is used to act in both advertiser and observer role.

Spec details used: nRF52832, SDK 15.2.0, S132 6.1.1

[Karl Ylvisaker]

Hello,

This sounds like you scanning window and interval is not matching the advertisement interval - I would think so based on your description that the performance is 'binary' either good or bad.
Please bear in mind that a random 0 - 10 ms delay is added to the beginning of every advertisement packet, to improve coexistence for 2.4 GHz devices. This delay is part of the BLE specification, and can not be altered nor removed. This might be contribution to causing your mismatch in advertising intervals vs. scan windows.

Could you attempt to change your scan window to 70 ms,, and see if this results in stable performance?
You current numbers suggest that there should be at least 1 advertisement picked up by the scanner for each window, since it at worst is 35 ms between advertisements, and your scanner is only scanning one of the three advertising channels each scan window.
If we can verify stable performance with the changed scan parameters then we may tweak it for better power consumption afterwards, such as increasing the scan interval.

Furthermore, the reception of the advertisement packet itself also takes some time.
You can use the online power profiler to estimate how long a single advertisement will take, based on the size of the payload.
In the case that your device has not finished receiving the advertising packet when the scan window is over, then the packet is lost.

Looking forward to solving this issue together,

Best regards,
Karl

[Jebakumar]

Hi Karl,

Thanks for your answer. We had also tested different scanning window and interval combinations. Your answer tells that the solution is properly adjusting the scanning interval and window. We will give a try again considering the random delay added to advertising interval. I will update you after our try.

Thanks a lot.

Regards,

Jebakumar.

[Karl Ylvisaker]

Hello Jebakumar,

Jebakumar said:

Your answer tells that the solution is properly adjusting the scanning interval and window.

This is my initial thought at least, when reading your description.
There are some other posts here on the forum that may be helpful to take a look at, that discuss the different scan intervals and window opportunities for different use-cases.

Jebakumar said:

We will give a try again considering the random delay added to advertising interval. I will update you after our try.

Great! Please post the different combinations you have tried as well, so I may have a look at the different combinations you have attempted - along with their results. This will be useful to see if it does not resolve your issue.

Jebakumar said:

We will give a try again considering the random delay added to advertising interval.

The random delay is known to cause mismatches in timing of advertising / scan intervals in between devices, but once it is properly accounted for things usually work out as expected.

I look forward to hearing your results.

Best regards,
Karl

[Jebakumar]

Hi Karl,

The performance has been improved after the following settings.

Scanning Interval = 100ms -> 105ms

Scanning Window = 50ms -> 70ms

Advertising Interval = 25ms

Advertising Duration = no timeout -> 1sec (advertising restarted after every 1 sec timeout period)

As per the above settings, scanning performance has been increased. there are situations where intended devices aren't discovered for few (1 - 3) seconds and then discovered. I think for social distance feature, this performance needs to be increased further.

Regards,

Jebakumar.

[Karl Ylvisaker]

Hello Jebakumar,

Jebakumar said:

The performance has been improved after the following settings.

I am happy to hear that you performance was increased by the changes. Could you speak to how much better the performance? Previously you said that you could receive as little as 0 or 1 packet per second, what is the packet reception rate with the changed scanning parameters?

Jebakumar said:

(advertising restarted after every 1 sec timeout period)

Could you elaborate on what you mean here, did you configure no timeout for the advertising duration, but you restart the advertising every second? What is your reason for doing this?

Jebakumar said:

there are situations where intended devices aren't discovered for few (1 - 3) seconds and then discovered.

This is not normal - 3 seconds is approximately 120 advertising packets missed over 30 scanning intervals - this is highly unlikely, especially if the devices are as close to each other as you previously mention.

Are you familiar with using the nRF Sniffer tool? It would be highly beneficial if you could send me a sniffer trace of the events in which the re-connection takes up to 3 seconds. This way, we can ensure that the peripheral is in fact advertising during this time.

Looking forward to resolving this issue together,

Best regards,
Karl