iBeacons are small coin sized devices, which emit a signal in the form of a radio frequency. They are based on the bluetooth low energy specification and many mobile devices already on the market contain the technology required to pick up the broadcasted signal. Essentially, they can be used to trigger an event or notification on a user’s device, when a user has a compatible application open. In practical terms, they are being marketed as an alternative to Near Field Communication (NFC) technology and are capable of being put to similar uses as NFC technology, though with a greater range.
I’ve been experimenting with iBeacons over the past month or so at work, trying to figure out the possibilities of what can be done with them. Experiences have been varied so far, with software based beacons, mostly in the form of the Estimote App (Android/iOS), proving to be really effective, and hardware based beacons being very erratic and tricky to work with.
So far my experience is with detection via an iOS app, built using the Titanium platform, in conjunction with an excellent iBeacon module. The module basically allows you to detect iBeacons within range and then handle the incoming data as you wish. The incoming data from each iBeacon includes things like the beacon id, rssi, broadcast strength and accuracy properties, along with a few other pieces of data which can be used to determine proximity and the iBeacon’s identity.
One of the biggest challenges so far, as I’ve mentioned, was in getting hardware iBeacons to work in a meaningful way. With the setup that I have been using, an event listener picks up the broadcasted signal, which is transmitted approximately once per second. The first problem is that, for some reason, the beacons transmit an extremely erratic signal, not only in the form of a signal which fluctuates at around +/- 10, it also throws out some anomalous 0’s so, the raw signal form each beacon is far from steady.
Tackling the anomalies was straight forward, simply filter out the 0’s from the incoming data, after that, you’re left with a more smoothly undulating signal. In order to achieve a consistent distance value, we can borrow similar sorts of techniques which are employed in other scenarios where it’s necessary to reduce spikes in an incoming data stream, for example, within audio processing, or stock market analysis. A technique known as Simple Moving Average (SMA) allows us to achieve a smoother stream of data by storing the past n# values within an array from which we can calculate an average value, whilst removing old values from the array as we add new ones, in order to maintain a small and timely, but more accurate sample. Using this array, we calculate the average.
This technique seems to be working really well and allows features like proximity sensing to work a lot more effectively. Prior to the SMA algorithm, beacons would jump in and out of view constantly, which made it really hard to stay fixed on one beacon, or even stay focused on that which was nearest.
Other than that, I’m still working on methods to improve the reliability of iBeacon signals and hopefully we’ll be able to make use of the technology in a meaningful way… as is often the case with the early adoption of most technologies, the initial learning curve can slow things down a bit, but as the nuances of the technology get worked out, it’ll be interesting to see how iBeacons get used in the real world.
Here are a few articles/posts which I found really useful in getting started with iBeacon technology:
http://www.warski.org/blog/2014/01/how-ibeacons-work/
I also found the eBeacon iOS app really helpful for messing around with the settings of hardware iBeacons, it’s available here: https://itunes.apple.com/us/app/ebeacon/id730279939?mt=8
Joseph Wilkins 