A year ago I first got my hands on a pack of Estimote iBeacons, I spent a bit of time working out their accuracy and quickly fell in love with them. The quick answer. Super accurate, within 10cm when you are 1 metre away.
What bothered me about the test is that it was static. The phone fixed in place and didn’t move in relation to the Estimote. This wasn’t representative of how iBeacons get used in practice. People holding mobile devices move around the place and ‘happen’ upon an Estimote. The settings I was using would sometimes feel like it took a minute or two before the mobile device registered that it was near an iBeacon. Estimotes are accurate, but sometimes it took a long time for the measurements to catch up with a moving target.
For the sorts of locative applications I write, a sixty second delay is unacceptable. After a bit of tweaking I got everything as responsive as I wanted, but it was a clumsy approach. So how long does it take for Estimote distance measurements to ‘catch up’ with a moving target?
There are four main settings that have an impact on Estimote response time. Two are set within your application and the other two on the Estimote beacon itself. The application side parameters are set with the ‘ForegroundScanPeriod’ method call. You can tell your application how long to spend scanning for iBeacons and how long to wait between scans. Altering these settings can make your application spend more time looking for iBeacons.
For the Estimote itself, the two parameters that affect response time are Broadcasting Power and Advertising Interval. A higher broadcasting power will mean that your phone will be able to hear the iBeacon at a further distance. While a lower advertising interval will send ranging pings more often. Naturally, upping these settings will burn through your Estimote battery at a faster rate. So getting all this right (and optimised for your application) is important. If the advertising interval on your Estimotes is set at 950ms, intuitively you would expect the median response time to also be around 950ms. Well lets find out.
To test, I built a little utility application for measuring response times. Placed the Estimote on the ground and measured out some markers. The nearest being 3 metres from the Estimote, this was my target. I then measured out 8 metres and 21 metres from the Estimote. These were going to be my two starting points. The 21 metre starting point being behind a large concrete cyclone resistant home (at this point, I was always out of range of the Estimote).
Walking from one of the starting points, I would walk up to my 3 metre mark and press start on my utility app. This started a timer, which would only stop when the distance returned by the Estimote SDK was between 2.1 and 3.9 metres. This wide error margin is the expected accuracy at this range, as found in my earlier test.
I did this ten times from each of the starting points for each of the configuration sets I tested. If you are after the raw measurements and stats, you can check out the full dataset and calculations here.
With the default Estimote settings (-12dBm broadcast power and a 950ms advertising interval), the median response time was 1300ms. Much higher than the 950ms I was expecting, but the worst case was a whopping 21000ms. This was inline with my experiences, having measurements to debunk earlier anecdotal experiences helped. Keeping the Estimote settings the same, and using 950ms for both the poll time, and poll wait actually made things worse.
By upping the broadcast power to -4dBm, and bumping the advertising interval to 600ms I was able to get a sub second response time. It also dropped that worst case wait down to around 6 seconds. Tolerable for my application, especially considering it is only a rare occurrence.
I’m having a second honeymoon with my Estimotes now that I can configure the right response times for the applications I build. Upping the power and lowering the advertising interval only had a modest impact on the battery life of my Estimotes. They are still claiming to have about two years of juice left.
Warning! Self promotion ahead: Live in Brisbane, Australia? Want to see Estimotes used in a neat little piece of Science Fiction theatre? Tickets for ‘This is Capital City’ are on sale now.
Comments:
You can join the conversation on Twitter or Instagram
Become a Patreon to get early and behind-the-scenes access along with email notifications for each new post.
Hi! Subconsciously you already know this, but let's make it obvious. Hopefully this article was helpful. You might also find yourself following a link to Amazon to learn more about parts or equipment. If you end up placing an order, I make a couple of dollarydoos. We aren't talking a rapper lifestyle of supercars and yachts, but it does help pay for the stuff you see here. So to everyone that supports this place - thank you.