Apple iBeacons(loopinsight.com)
loopinsight.com
Apple iBeacons
http://www.loopinsight.com/2013/09/20/apple-ibeacons/
15 comments
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.
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.
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.
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.
It should be straightforward with BlueZ 5. Good luck finding documentation on how to do it though.
This gigaom post has more details on iBeacon: http://gigaom.com/2013/09/10/with-ibeacon-apple-is-going-to-...
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.
More like 314 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.
More like 314 square meters.
> 2,500 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).
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).
> > you need 1 Estimote beacon for every 100 square meters.
> More like 314 square meters.
But you can't pack circles tightly -- you have to use hexagonal cells.
> More like 314 square meters.
But you can't pack circles tightly -- you have to use hexagonal cells.
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.
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.
Hey, this is Jakub from Estimote.
We have been working on wireless Bluetooth Smart beacons long before Apple made it part of their Core Location API and called iBeacon.
If you would like to learn more about Apple iBeacon you could check it here: https://developer.apple.com/library/ios/documentation/CoreLo...
Our API and BLE beacons in general are explained here: http://www.estimote.com/api
We have been working on wireless Bluetooth Smart beacons long before Apple made it part of their Core Location API and called iBeacon.
If you would like to learn more about Apple iBeacon you could check it here: https://developer.apple.com/library/ios/documentation/CoreLo...
Our API and BLE beacons in general are explained here: http://www.estimote.com/api
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.
It should be completely doable in Android 4.3, but you'll have to do it via the Bluetooth API instead of a location API.
I think its everyones dream to walk into a store, type what you're looking for into your phone and see how far it is away from you.
How cheap would these have to be in order to make them cost effective to put into every day product packaging?
And would too many of these near each other cause too much interference?
This would be a great way to cut the store out of the solution and just go straight from product -> customer?
How cheap would these have to be in order to make them cost effective to put into every day product packaging?
And would too many of these near each other cause too much interference?
This would be a great way to cut the store out of the solution and just go straight from product -> customer?
> I think its everyones dream to walk into a store, type what you're looking for into your phone and see how far it is away from you.
Soon you won't even need to go to a store, the things you want will be dropped off to your home or business...
Soon you won't even need to go to a store, the things you want will be dropped off to your home or business...
I believe the future in the short term would be something like BufferBox
http://en.wikipedia.org/wiki/BufferBox
"temporary parcel pickup station for packages ordered online"
https://www.bufferbox.com/
I want to do something like this in my country.
http://en.wikipedia.org/wiki/BufferBox
"temporary parcel pickup station for packages ordered online"
https://www.bufferbox.com/
I want to do something like this in my country.
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.
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 :)
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
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
This is informative:
http://estimote.com/api/index.html
Doesn't seem like there's a standard API yet.
http://estimote.com/api/index.html
Doesn't seem like there's a standard API yet.
Besides Estimote, another startup that provides dev kit including Bluetooth LE Beacon and API is kontakt: http://kontakt.io
For people pursuing this, it's worth looking back at the successes and failures of Jini, from both technical and market perspectives.
...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?
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?
What specifically has Jini got to do with this?
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.
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's another company with iBeacon style sensors that I've seen at ArtPrize in Michigan called GeLo: www.gelosite.com
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.
Here is a good article that describes some scenarios that provide a glimpse into iBeacon's potential:
http://www.computerworld.com/s/article/9242393/Why_Apple_s_i...
http://www.computerworld.com/s/article/9242393/Why_Apple_s_i...
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.
Can someone tell me how this compares to something like StickNFind?
https://www.sticknfind.com/
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.
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?
Does anyone know if there is an open version of these motes? And what phones other than the iPhone support bluetooth low energy?
See http://www.bluetooth.com/Pages/Bluetooth-Smart-Devices.aspx
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.
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.
Isn't this just another spin on NFC?
With greater range. NFC has a practical range of about 4cm; iBeacon has a range of about 10-20m.
Ah, then it must be Bluetooth Low Energy.
Correct, it's also not based on RFID like NFC is, and so can in theory be used for a whole lot more.
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.
This is awesome! I've been looking for something like this for a while, thanks a lot for the tip.
With just the rough description I've seen I'm almost certain that it's just devices supporting the Low Energy Proximity profile.
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.
Like I said, a complete branding disaster.
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.
Like I said, a complete branding disaster.
Leave it to an industry SIG. USB hi-speed vs. full speed all over again.
What's the solution to these expected failures in branding and their impact on us consumers?
What's the solution to these expected failures in branding and their impact on us consumers?
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)
PayPal is building an iBeacon too for payments in store.
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.
Hi, this is Jakub, Co-founder of Estimote (YC S13).
That's correct and any iOS device (iPhone, iPad, iPod Touch) could be turned into a beacon.
We have even developed a Virtual Beacon app you could already download from the App Store and simulate beacon and proximity: https://itunes.apple.com/us/app/estimote-virtual-beacon/id68...
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
That's correct and any iOS device (iPhone, iPad, iPod Touch) could be turned into a beacon.
We have even developed a Virtual Beacon app you could already download from the App Store and simulate beacon and proximity: https://itunes.apple.com/us/app/estimote-virtual-beacon/id68...
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.