Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
With Bluetooth Low Energy, you specify a scan window (how long to scan) and interval (how long to wait between scans).
Would there be any difference between scanning for 10 ms every 100 ms, or scanning for 1 sec every 10 sec? Seems like the chance two devices find eachother (have their radios on simultanously) should be equal in that case?
Is there a simple formula to calculate the right window/interval based on the maximum time allowed to connect?
According to the Bluetooth 4.0 core specification the time period of 'advertising events' are as shown below for the different types of advertising packets:
ADV_IND: General connectable and scannable advertisement packets' time period ranges from 20 ms to 10.24s in steps of 0.625ms.
ADV_DIRECT_IND: Directed advertisement packets' time period is less than or equal to 3.75 ms. This kind of advertisement events can happen consecutively only for 1.28s. This is for a establishing a quick connection (if there is a device listening).
ADV_NONCONN_IND: Non-connectable and non-scannable advertisement packets' time period ranges from 100 ms to 10.24s in steps of 0.625ms.
ADV_SCAN_IND: Scannable advertisement packets' time period ranges from 100 ms to 10.24s in steps of 0.625ms.
So, unless you know the kind of device you are scanning for a good approach would be continuously to scan for around 11 (max) seconds to see if there are any advertising devices around. How often to do this will depend on the amount of battery or power available.
Hope this helps.
There is another aspect to this that is being missed in the other answers. As per the Core BLE specification, only one advertising channel is being looked at during each scanInterval and is rotated to the next of 3 channels with each interval. So if there is RF interference on that channel you might not see the device even if you have the scanWindow equal to the scanInterval in order to do continuous scanning.
The BLE peripheral device that does advertising would normally rotate through all three advertising channels in sequence very quickly during each advertising blip of time. So the best central device scanning algorithm would have shorter windows and intervals in order to sequentially check each advertising channel. Apple apparently uses a 30 ms scanWindow with 40 ms scanInterval in iOS with apps in foreground mode. That means that each advertising channel will be checked every 40 ms. Per the BLE Core Specification:
Each advertising event is composed of one or more advertising PDUs sent on used advertising channel indices. The advertising event shall be closed after one advertising PDU has been sent on each of the used advertising channel indices (see Section 4.4.2.1) or the advertiser may close an advertising event earlier to accommodate other functionality.
Another very important aspect is to have the Peripheral device set an advertising interval that is relatively prime compared to the scanInterval on the Central device. This is why Apple specifies specific advertising intervals. If you were to pick a scanInterval of 100 ms with a scanWindow that was smaller, say 80 ms and had an advertising interval of 1000 ms (1 second), then you could get unlucky and always be advertising during the 20 ms when the Central device was not scanning during each scanInterval. In reality, the BLE core specification adds a random 0-10 ms to the advertising interval which helps slew to prevent a complete deadlock, but it's really done more to avoid multiple devices advertising at nearly exactly the same time from interfering with each other forever.
For all undirected advertising events or connectable directed advertising events used in a low duty cycle mode, the time between the start of two consecutive advertising events (T_advEvent) is computed as follows for each advertising event:
T_advEvent = advInterval + advDelayThe advInterval shall be an integer multiple of 0.625 ms in the range of 20 ms to 10.24 s. If the advertising event type is either a scannable undirected event type or a non-connectable undirected event type, the advInterval shall not be less than 100 ms. If the advertising event type is a connectable undirected event type or connectable directed event type used in a low duty cycle mode, the advInterval can be 20 ms or greater. The advDelay is a pseudo-random value with a range of 0 ms to 10 ms generated by the Link Layer for each advertising event.
Think of having two frequencies near each other and how you get a beat frequency of their difference. That is essentially what can happen between the scanInterval and the advertising interval. Apple did a decent job with their settings for this so following their standards would not only work well for iOS but also for Android. Apple's foreground mode of 30 ms scanWindow with 40 ms scanInterval means that for a base advertising interval of 1022.5 ms that you see the device within 1 second about 3/4ths of the time and always within 2 seconds, assuming no RF interference obscuring the advertising packet. In background mode with a 30 ms scanWindow and 300 ms scanInterval, the median time becomes 5 seconds and the usual maximum becomes 19 seconds though with very bad luck of the random shifts it could be a little longer.
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
The Apple recommended peripheral advertising intervals are 152.5, 211.25, 318.75, 417.5, 546.25, 760, 852.5, 1022.5, 1285 ms.
I find @EarthLord's answer misleading and thus I want to share my answer:
I think you misunderstand what an interval and window is in that specific scenario. A window specifies a time in which a device listens for advertisements and optionally requests scanrecords. The interval defines the time between to consecutive windows.
In the Bluetooth Core Spec 4.0 it says
The scanWindow and scanInterval parameters shall be less than or equal to 10.24 s. The scanWindow shall be less than or equal to the scanInterval. If the scanWindow and the scanInterval parameters are set to the same value by the Host, the Link Layer should scan continuously.
Which means set both to 5 frames and you will have a scan continuously. How ever if you do an active scan (which means you request scanresponse) you should not do that. Any battery driven Peripherals will be sucked out very fast.
Instead define a interval that works for your application and set a scanwindow that is smaller than it.
However I don't think there is some default value for this.
