I've implemented this as a hackathon project a month ago (an iPhone serving as a broadcaster and an iPad serving as a receiver). It's an awesome technology with a lot of promise but my one BIG gripe is the imprecision of RSSI. At home, the proximity indicator was somewhat accurate. At the office the proximity indicator was not accurate at all - half the time it would be good but the other half it would show the unpredictbale/interchangeable RSSI whether the receiver was at a yelling distance or a whispering distance. (Maybe due to signal interference)?
If RSSI cannot be relied upon, it severely limits the utility of iBeacons. A "binary" result (beacon found, beacon not found) can be useful but not near as useful as a reliable distance indicator. For example, my goal for the hackathon was to see if equipment in a lab could be activated by walking around with your phone. If the phone cannot tell that I am closer to equipment A than equipment B, then there is no point and moreover, we should not be referring to this new technology as "micro locations".
Having said that, I know of a company here in Minneapolis piloting iBeacons as indoor navigation (to find your way in a mall for example). I don't know if their technology works because they've found a way to ensure more correct RSSI readings, or if they are simply relying on the assumption that stores are far enough apart.
RSSI imprecision is just the nature of the BTLE. Bluetooth signals tend to bounce around in room that is full of objects, heavy metal blocks signals, etc.
To solve the problem, this can be accomplished by collecting an array of RSSIs and averaging them to get a more accurate result over time. Being said, for time sensitive use cases, it's pretty challenging to use iBeacons. Nevertheless, iBeacons has a lot of potentials.
I also think iBeacon will eventually dominate the proximity detection market. Here are 3 reasons:
1. Apple has a dominant smartphone market influence.
2. Apple released the iBeacon spec into the wild, and there will be more companies manufacturing iBeacons like estimote.
3. Google's BLE API is not that mature yet.
RSSI imprecision inherent in BTLE is exactly the point I wanted to make. The marketing around BTLE focuses on "micro locations" but I feel that that's misleading given that in the real world, you cannot reliably get even approximate precision (let's say 5 feet) let alone micro precision. Human walking speed alone is enough to blow the whole "micro" concept out of the water.
Another sticking point for me is the battery life. The transmitters are touted as low energy, which they are, being able to transmit for 2 years on a watch coin battery is amazing. However, a transmitter is useless without a receiver (did the tree really fall...) and the receiver is going to be anything but low energy if has to continually scan and compare surrounding signals. Granted, my demo receiver app was as unoptimized as you can get (one day of coding plus I am not even an iOS developer) but at the same time, it didn't do much but look for signal, and it was chomping through battery at an alarming rate. It was ok for a 5 minute demo but I can't imagine real users would put up with this for long.
Given these two limitations, I have a hard time imagining wide adoption.
They are not exactly "micro locations" (as far as I concern), it's more like proximity (did something get close?). And I think people should set their expectations of BTLE straight.
There could be different kind of receivers. It could be something plugged into the wall and it doesn't have to consider battery consumption any more. And if the transmitter is transmitting at a high enough frequency, an iphone running in background mode could still pick up a signal really quick and conserve battery at the same time.
The thing is they dont't have to work as a receiver. It's enough to pinpoint you to given location using data sent by iBeacon. Everything else can happen between your smartphone and web-based services that would provide more context, data or feedback to your actions.
Since you've got some experience with it, do you have any idea how hard/easy it'd be to get an iBeacon working from a Raspberry Pi equipped with a Bluetooth dongle?
I used Apple-provided bluetooth capabilities so my experience is probably not particularly relevant to Raspberry Pi, sorry. One thing to think about is battery life, unless you only need to pair the broadcaster and the receiver once. What I mean is, if you have a listener that is constantly scanning for a signal and doing some logic depending on the signal strength, you are bound to have battery life as your biggest challenge and potentially a deal breaker to any real use.
iBeacon’s range is 50 meters (typical Bluetooth range), or 2,500 square meters.
That's some weird antenna right there. Assuming it's omnidirectional with a 50m range (radius) then it would cover more like 7,800 square meters.
The range of Estimote’s beacons is 50 meters, but the recommended range is 10 meters. If you go with the recommendation, you need 1 Estimote beacon for every 100 square meters.
I'm not sure it's a weird antenna. Looks like the author took 50^2 (square with edge length 50 m) instead of \pi 50^2 (the traditional interpretation of 50 m range).
Hmm, reading that after the estimote pages makes it seem that the gigaom post is just guerrilla marketing for estimote, that's trying to hijack the Apple publicity.
Have Apple actually stated anything public other than the word "iBeacon"?
Googling around I just find the same rewritten PR material all about estimote, not iBeacon specifically.
I'm so glad this is out of NDA. My coworker and I rushed through our lunches at WWDC to play with this. The API is so easy, and possibilities of what it can be used with are so broad. The immediate massive downside is that it's iOS only. But, it's a relatively open spec, so porting some logic in a non-copied way should be possible.
You mean like amazon prime? I'll admit amazon isn't always the cheapest, but with subscriptions and whatnot, its way nicer to have things mailed to me.
That said the environmental impact of shipped boxes may not be better overall. But damn is it convenient.
Google Shopping Express puts Amazon Prime to shame. Same-day delivery, and some of the pricing is cheaper than Amazon (some is more expensive). Selection is, of course, more limited since it's just started this year.
It's bagged up, so less cruft than Amazon which has to worry about freight delivery.
Neither does groceries, so I'm stuck with Safeway deliveries for that (which hasn't been a completely stellar experience).
I would be singing the praises of InstaCart, but they happened to no want to deliver to my area of the SF bay yet :)
That's a great vision and we at Estimote are really into it. But be believe there will always be goods you need to touch and try before you buy (expensive cameras, furnitures, even fashion).
Retail stores with sensors could deliver you both great showrooming experience and mobile commerce, something people already do anyway trying in Best Buy and buying from Amazon :P
...it's worth looking back at the successes and failures of Jini
Could you delve into the relationship between the two? I haven't read much about iBeacons; are they based on the "tuple space" model, or was Jini initially intended for the same market?
Jini was trying to solve the same sorts of problems. I mention it because when we look at a new technology, it's often instructive to look at older technologies that were trying to solve the same (or similar) problems. In particular, it's helpful to look at why they succeeded and why they failed.
For example, the "web services" community would have been well-served by looking at the successes and failures of CORBA, since the web services folks mostly replicated all the mistakes of CORBA.
Was that really an accident? I know many of the WS-* proponents liked to say, "This new web-based technology will be so much simpler than that crufty old CORBA junk." But in many cases it was the same companies with the same agendas doing the design and standardization work, so it's not too surprising that the result was more or less bound to go down the path of CORBA. The main difference, and of course the main motivation, was a protocol that would run on port 80 and have a chance to be "web-routable" through firewalls.
That's a really good point. Certainly the product vendors had the same motivations. But at the time I was often disappointed when I listened to the conversations of developers I worked with, because I rarely heard anyone draw parallels between the two. It was frustrating to work on projects where we'd be six months in and people would be surprised that the ORBs - er, I mean web service platforms - had difficulties talking to one another.
It wasn't just the product vendors. The people on the two specs were also the same. WS-* was literally the ex-CORBA contributors reimplementing all the same stuff.
I don't really see how Jini was trying to solve the same problems. iBeacons are really just a simple way to discover devices nearby broadcasting a UUID. Jini was a super complicated attempt to create a distributed device fabric, which included interface negotiation and driver distribution and all kinds of other complex infrastructure, most of which is redundant now.
There is also Tile (http://www.thetileapp.com/) which is using them as a way of distributing the finding of lost things. It's an interesting concept, but something I'd never do.
I have to imagine iBeacons could be more about the iwatch than the iPhone. I don't want to take my phone out of my pocket all the time to check for new notifications. I would glance at my watch.
StickNFind or Tile are designed to be sticked to moving objects in order to estimate their location from owner phone.
Estimote is designed to be sticked to fixed location. Think about it as a lighthouse that is broadcasting its presence and location, so smartphones and other smart devices could estimate their relative location and get the context.
So that implies that the app locating these fixed beacons needs some kind of data backchannel to understand what it's seeing? Unless you have a cached map of that particular store and it's beacons already in your device, right?
The Galaxy S3 and S4 have home grown BLE stacks and Android 4.3 has finally announced BLE support in the stack so it should show up on Android phones that get the update (the hardware has been there for ages.) Blackberry 10 announced support this summer.
There are lots of cool things, easiest way to get started on the peripheral side is to buy a TI Dev kit "Cow Bell" http://www.ti.com/tool/cc2541dk-sensor?DCMP=blestack_ota&HQS... , its pretty cool. Temperature sensor, Magnetometer, Humidity, Pressure etc. you will have to flash it to support HID instead of GATT.
it is BLE or BlueTooth 4 ( same thing) , small difference is that iOS supports a HID over the more standard Gatt profile . Ultimately the end the BLE 'beacon' - 'bug' - 'responder' device is likely a TI CC2540 chip or similar mfg ( I think there is another swedish mfg that provides a similar system )
Just a nit, but BLE and Bluetooth 4 are not the same thing. The Bluetooth SIG has made complete mess of the situation. The Bluetooth 4 specification defines both BLE and Bluetooth "Classic" which use different radios. You can label something Bluetooth 4 when implementing only one of the modes or both.
The marks you need to look for are Bluetooth Smart and Bluetooth Smart Ready. Bluetooth Smart is reserved for devices that only implement the BLE radio and this is what you'll see on things like FitBits, etc. The Bluetooth Smart Ready is reserved for devices that implement both Bluetooth Classic and BLE. The iPhone 4S+ is Smart Ready, Android 4.3 will be Smart Ready, etc.
It has already bit Nike in the butt when people flipped out when they said they weren't going to support Android with the Fuel Band. The reasons were completely technical, but consumers assumed it was because Nike was some how saying Android was inferior. Of course, trying to communicate this in a tweet also makes the problem even worse.
Bluetooth low energy yes, but I'm not sure it's fully available to applications. iBeacon is more specific and dedicated to location calculation (it's part of core location)
It's worth noting that iOS devices themselves can serve as beacons - so, for example a payment terminal app running on an iPad can announce itself to nearby iPhones.
If one wants to pickup the Virtual Beacon's signals programmatically then our API website could be helpful where we have included source code of few apps http://www.estimote.com/api
If RSSI cannot be relied upon, it severely limits the utility of iBeacons. A "binary" result (beacon found, beacon not found) can be useful but not near as useful as a reliable distance indicator. For example, my goal for the hackathon was to see if equipment in a lab could be activated by walking around with your phone. If the phone cannot tell that I am closer to equipment A than equipment B, then there is no point and moreover, we should not be referring to this new technology as "micro locations".
Having said that, I know of a company here in Minneapolis piloting iBeacons as indoor navigation (to find your way in a mall for example). I don't know if their technology works because they've found a way to ensure more correct RSSI readings, or if they are simply relying on the assumption that stores are far enough apart.