So I’ve noticed that the didRangeBeacons method gets called once a second. If that’s the case why would you want to set the advertising interval at less than 1000ms?
Remember that some of the advertising packets from beacons will get lost: the radio signal can be absorbed by a human body, or bounce of a wall. And you actually need the advertising packet to overlap with scan period on the iPhone. So the lower the interval, the greater the chance signal will be properly received.
1 Like
Thanks, that makes a lot of sense.
Another reason: the “extra” packets are used to better estimate the distance to the beacon. If one packet says “5 meters”, but 4 other packets say “1 meter”, then iOS figures the truth is rather somewhere around 1m than 5m (:
1 Like
Interesting thanks. I don’t suppose there’s a a way to speed up calls to the didRangeBeacons? So instead of 1 second make it half a second.
Not on iOS. Android gives you control over those settings, but iOS does not expose access to probing frequency.
Yup. Just curious, why would you need it more often than 1 second, what’s the use case?
This goes back to using the beacons to help those with sight loss understand their environment. Surprisingly I didn’t realise how far you could travel past a beacon in just one second. Decreasing that to half a second could make a considerable difference.
Hmm, interesting. Not much we can do with Core Location, but we’ll keep that in mind for when we start expanding towards Core Bluetooth. Although that probably won’t come earlier than with the next-gen beacon firmware and hardware.
FYI: from a deployment perspective, we haven’t seen any use cases or real implementations that require a super, super fast advertising interval. Overwhelmingly, most customers I’ve worked with use somewhere between 350 - 1000 ms, depending on their specific use case.