This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to improve Social Distance scanning performance?

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

Parents
  • 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

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

Reply Children
  • 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

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

  • 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

  • Hi Karl,

    Before answering to your questions, I should let you know one thing. Our application getting enough number of advertising reports including both intended and unintended devices for every seconds. But the scanning performance towards intended devices was not up to the mark some times. We just used power profile tool and it is showing the scanning interval and advertising interval as the power changes during RF activity. 

    Could you speak to how much better the performance?

    Before it was such that there was no scanning or one scanning reported per second for the intended devices until next power cycle. But now it is that in the same power cycle, after few seconds of zero or one advertising report it becomes normal, it means we are getting 3 to 10 reports.

    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?

    I configured the advertising timeout to 1 sec. Advertising restarted after every timeout. Even if two device start the scanning same time, due to random delay added in advertising will make them to scan each other enough, right? As we faced performance issue I thought to restart advertising periodically with timeout. 

    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.

    It is not about re-connection issue. I have used the sniffer before. I will try to take sniffer trace after few configuration tests.

    Regards,

    Jebakumar

  • Hello Jebakumar,

    Jebakumar said:
    Before answering to your questions, I should let you know one thing. Our application getting enough number of advertising reports including both intended and unintended devices for every seconds. But the scanning performance towards intended devices was not up to the mark some times. We just used power profile tool and it is showing the scanning interval and advertising interval as the power changes during RF activity. 

    Thank you for being more specific about your application - this helps me understand your issue better.

    Jebakumar said:
    Before it was such that there was no scanning or one scanning reported per second for the intended devices until next power cycle. But now it is that in the same power cycle, after few seconds of zero or one advertising report it becomes normal, it means we are getting 3 to 10 reports.

    Hm, strange that you are going a couple of seconds with either zero or one advertising report..
    Could you use the sniffer tool as suggested, to check how many advertisements that are being sent, compared to how many that are received in the time period?

    Jebakumar said:
    I configured the advertising timeout to 1 sec. Advertising restarted after every timeout. Even if two device start the scanning same time, due to random delay added in advertising will make them to scan each other enough, right? As we faced performance issue I thought to restart advertising periodically with timeout. 

    I do not think it should matter that you restart advertising every 1 second - I do not think this should have any kind of positive impact on the performance.
    I am not sure I understand your questions here either - if they start scanning and advertising at the same time then the windows will drift off of each other due to the random delay, yes - but you may account for this, by having a sufficiently large enough scan window.

    Jebakumar said:
    It is not about re-connection issue. I have used the sniffer before. I will try to take sniffer trace after few configuration tests.

     Great! Seeing a sniffer trace along with the description you are providing would be very useful, thank you.

    Best regards,
    Karl

Related