6 ms·

Google’s Eddystone – a flexible, open-source iBeacon alternative

146 points by Rican7 11y ago

ge0rg 11y ago
This is a really interesting idea. iBeacon is way too inflexible in what you can encode in it. I really dislike the decision to make it part of the Play API (as opposed to standard Android), as it ends up not being really open after all. I wish they would also document their packet format. At least they write that they support parallel operation as Eddystone + iBeacon [1], which means that they probably use the BLE "advertisement" frame for the iBeacon and the BLE "scan response" for the Eddystone data. With both frames limited to 29 bytes, there is not much space to toy around. [0] http://developer.radiusnetworks.com/2015/07/14/introducing-eddystone.html http://developer.radiusnetworks.com/2015/07/14/introducing-e... [1] http://altbeacon.github.io/android-beacon-library/eddystone-support.html http://altbeacon.github.io/android-beacon-library/eddystone-...
- yresnob 11y ago
  isn't the link on their github to the packet format? https://github.com/google/eddystone/blob/master/protocol-specification.md https://github.com/google/eddystone/blob/master/protocol-spe... I love this release Google needed to take a direction there are so many use cases for this sort of micro proximity I cannot wait to see what folks can do without freaking people out over privacy..
- tdicola 11y ago
  It looks like they've documented the packet format here: https://github.com/google/eddystone https://github.com/google/eddystone For example URLs: https://github.com/google/eddystone/tree/master/eddystone-url https://github.com/google/eddystone/tree/master/eddystone-ur..., UIDs: https://github.com/google/eddystone/tree/master/eddystone-uid https://github.com/google/eddystone/tree/master/eddystone-ui..., and telemetry: https://github.com/google/eddystone/tree/master/eddystone-tlm https://github.com/google/eddystone/tree/master/eddystone-tl...
- GauntletWizard 11y ago
  Binding things to the Play API has been an unfortunate compromise for Android; their product partners have not been forthcoming on continued device support, so google has had to bundle more and more as an updatable package rather than as part of the core OS. It's a shame that it's been this way, but in the prisoners dilemma of older device support, LG/Samsung/Etc have chosen to rat many, many times, and Google had to do something.
  - myko 11y ago
    It would be nice if the bits of Play Services that could be open sourced were open sourced.
    - gress 11y ago
      They could all be open sourced. Google chooses not to open source them in order to control the platform and develop leverage over their partners.
    - GauntletWizard 11y ago
      Bits like this can be and are open sourced; they're just not as usable open sourced, because obviously they're yet another library to grab and install. All the code you need to interface with it seems to exist on github, though not in nearly as pretty a package.
- magicalist 11y ago
  As others noted, the packet format is documented. But this: > I really dislike the decision to make it part of the Play API (as opposed to standard Android), as it ends up not being really open after all. doesn't really make sense. How do you open source storing data associated with a beacon in the cloud? The beacon is dumb so it's the client program that associates the broadcast with some action. The only way to open source that is to document the format of the beacon broadcast and release tools to let anyone receive them and parse them, after which any action can be taken. Which is exactly what was open sourced. The Play Services support seems to just be that you don't have to do it yourself if you don't want to on Android™ devices, because play services already has support. If they really want this to take off in iOS apps, though, the only real way they can help developers out is by releasing source directly, I believe (the git repo includes an example iOS app[1] but I haven't looked at it yet) [1] https://github.com/google/eddystone/tree/master/tools/ios-eddystone-scanner-sample https://github.com/google/eddystone/tree/master/tools/ios-ed...
ble52 11y ago
Eddystone for dummies: https://www.youtube.com/watch?v=jSDnf4In6QI https://www.youtube.com/watch?v=jSDnf4In6QI
tdicola 11y ago
This looks really cool, in particular the telemetry packet is a nice idea for transmitting sensor data with BLE broadcast packets. Using that you can 'passively' read many nearby sensors without having to connect to them. I've had some similar ideas and played around with doing similar things using a nRF51822 (like a BLE radio + little cortex M0 chip) but ran into a ton of trouble with the BLE API's of various operating systems (like CoreBluetooth on OSX and bluez 5.3 on Linux). In particular most BLE implementations like CoreBluetooth and bluez have a lot of caching and assume that a device's broadcast & advertisement data rarely changes. This causes a ton of trouble when you put frequently changing data in broadcast packets since you can easily get stale or cached data instead of the most recent broadcast. I'd love to know if the Eddystone developers ran into similar issues with their telemetry packets and had any workarounds.
- IshKebab 11y ago
  This isn't a problem with the BLE implementations. It's in the BLE specification! > Duplicate advertising reports are not required to be sent to the Host. A duplicate advertising report is an advertising report for the same device address while the Link Layer stays in the Scanning State. The advertising data may change; advertising data or scan response data is not considered significant when determining duplicate advertising reports. Advertising really is designed to advertise the presence of a device. It isn't for putting data in - for that you should connect to the device.
  - tdicola 11y ago
    I'd argue its an omission or mistake with the spec then. Being able to passively collect sensor data without connecting to a device is very handy as it allows many devices to read data from many local sensors. If they all have to connect to each sensor then there's contention over the connection (only one device can connect to a sensor at a time) and it wastes power to setup and tear down the connection constantly (negating the whole point of BLE). If advertising isn't for putting data then arguably iBeacon, URI Beacon, Eddystone, etc. go against the spirit of the BLE spec.
mindcrime 11y ago
> The name "Eddystone" might sound a little weird, but Google says it's named after the Eddystone Lighthouse in the UK Damnit Google! Naming things after light-houses is our "thing"![1][2][3][4] :-) All joking aside this sounds like a pretty cool project. And anything that helps keep as much IoT infrastructure open-source as possible, is a Good Thing in our book. I'm actually really hoping this catches on and displaces iBeacon as much as possible. [1]: https://github.com/fogbeam/Quoddy/ https://github.com/fogbeam/Quoddy/ [2]: https://github.com/fogbeam/Neddick/ https://github.com/fogbeam/Neddick/ [3]: https://github.com/fogbeam/Heceta/ https://github.com/fogbeam/Heceta/ [4]: https://github.com/fogbeam/Hatteras/ https://github.com/fogbeam/Hatteras/
- socceroos 11y ago
  Funny the things you stumble across when reading through user comments. Love what you're doing. In your 'travels', have you come across the need to integrate your services with the TechnologyOne line of products? Information insight is a problem the company I work for struggles with immensely.
  - mindcrime 11y ago
    I'm not familiar with TechnologyOne's products, but I'll look them up. If you'd like to talk about it offline, feel free to drop me an email. prhodes@fogbeam.com
jackgavigan 11y ago
The problem with Google is that you don't know if any product/service they launch will still be supported in a few years' time, or if the product/engineering team will lose interest and move on to build the next shiny thing.
- wstrange 11y ago
  This meme is getting tired. Plenty of other companies EOL products.
  - jackgavigan 11y ago
    It's not a meme, it's a cliché. And it's a cliché because it's true. Edit: Coincidentally: https://news.ycombinator.com/item?id=9888387 https://news.ycombinator.com/item?id=9888387
binarymax 11y ago
This really needed to happen to help push the physical web forward. Beacons by the suppliers have just been too expensive. Last year at Full Frontal Conf, Scott Jenson said URIBeacons would cost 'a fiver'...but the cheapest I've ever seen has been $15 each (and that's in bulk). Really glad to see this! Hopefully soon I'll be able to buy dozens of these on the cheap for a serious project.
- BenSS 11y ago
  You can definitely get the hardware for <$15 in bulk if you source it yourself. There's a huge variation in quality though, as with most of the China stuff. If you're willing to deal with the caveats&lock-in of the Gimbal Beacons you can get those for $5. Feel free to hit me with beacon questions, I've got a bunch of varieties sitting on my desk right now.
  - eggie5 11y ago
    what are the caveats of Gimbal?
    - BenSS 11y ago
      Shorter range, proprietary setup/configuration process, cycle IDs (crashing some android bluetooth stacks). They really want you to pay for the backend - wouldn't be surprised if they're sold at cost. The batteries don't last as long as advertised either, but that's pretty much been true for all of the devices I've tested.
ignoramous 11y ago
> Google gets the best of both worlds here. As an open source project, Eddystone gets lots of hardware support from vendors, but if developers want to give users the best experience and have an easier time themselves, they have to submit to the walled garden. Eddystone doesn't need to be tied to Google though, and if developers want to use their own cloud solution or client API This is a killer. This isn't really open source at all [0]. Google controls the eco-system, and has most of the other vendors at its mercy (like how they flip search algorithms, give Google products a prominent listing in the search page, blacklist developers/websites etc). More than Search, its the mobile OS and API monopoly that Google is trying to build that's going to hurt even more. I work on AOSP, and I think it is ridiculous that Google owns so much of the eco-system [1] and continues to get praised for being "open" as well; very much like how this article seems to be praising them now. Besides, whatever happened to proposing to a central body and getting stuff standardized (I get that its political and slow, and no ones like slow)? Google works with W3C to get stuff in the HTTP standard [2], with ECMA too [3], but seems to have problem engaging standards body for other things where it has a near monopoly. Not long after Chrome has taken over a large market share, Google would start treating W3C the same, if it hasn't doing been that already [4]. [0] http://techcrunch.com/2009/12/22/google-open-when-convenient/ http://techcrunch.com/2009/12/22/google-open-when-convenient... [1] http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/ http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-... [2] http://www.tomsguide.com/us/google-spdy-http-internet-w3c,news-13990.html http://www.tomsguide.com/us/google-spdy-http-internet-w3c,ne... [3] https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ [4] http://www.neowin.net/news/microsofts-pointer-events-becomes-w3c-standard-google-and-apple-play-hardball http://www.neowin.net/news/microsofts-pointer-events-becomes... /rant /offtopic
- dannyr 11y ago
  But then people complain that Samsung, HTC, etc changes Android so much that they clamor for Google to control the OS more. Damn if you do, damn if you don't.
  - pjc50 11y ago
meatysnapper 11y ago
The pity is that BLE on Android has sucked, horribly badly, consistently. Google needs to have their hardware have a minimum level of support for basic stuff, and then we can talk. In contrast, Apple's BLE implementation is robust and works well for since the iPhone 4S, and reliably on all the newer platforms
- derwildemomo 11y ago
  This. I'm currently working on my 3rd Android-BLE project and it's incredible how bad those APIs (and of course the vendor's implementations) are. An inconsistent pile of .. well, nothing nice. I don't get why they have no interest in fixing that..
- desdiv 11y ago
  Could you please elaborate on where the suckiness lies? Was it particular devices, or particular phone manufacturers? Or was it something wrong with the Android BLE APIs?
  - meatysnapper 11y ago
    Everywhere possible: 1) Different levels of support on different hardware 2) Doesn't support half the BLE spec (Peripheral) 3) Limited functionality on the Central side, only supported 4 Peripherals last time I checked 5) Buggy in general Just like we don't trust Apple to build cloud services that don't suck, we don't trust Google to build a consistent hardware/OS experience across Android. This is stuff that is not sexy, but it has to be done, and it's exactly what you expect to be done by a company that doesn't have 30+ years in building their own hardware + OS.
polskibus 11y ago
I hope I'll be able to upgrade my Texas Instruments' SensorTag to be Eddystone compatible in the future.
- jonlucc 11y ago
  Yesterday, I received some HM-10 BLE boards I ordered a bit ago. I hope the firmware will be updated, but I'm not holding my breath.
  - guidefreitas 11y ago
    Yeah, same situation here.
IshKebab 11y ago
This still has their weird URL encoding scheme though. To use it you have to own a very short domain on a common TLD. Kind of limiting.
tuyguntn 11y ago
Maybe offtopic, but does anyone here knows how to manufacture iBeacons?
guelo 11y ago
Yea but as long as iPhones are locked down so they can only talk to iBeacons then no other BLE beacon is going anywhere.
choppaface 11y ago
So is the major advantage of Eddystone that Google will implement it and won't sue you for using it in ways they don't like? Eddystone isn't alone; there's AltBeacon, which is also an 'open' alternative: http://altbeacon.org/ http://altbeacon.org/ Though it looks like they might be 'merging' with Eddystone. AltBeacon was born out of Apple giving Radius Networks a cease & desist about a year ago for reverse-engineering the iBeacon protocol and distributing an open-source Android toolkit (with paid enhancements) for iBeacons: http://beekn.net/2014/07/ibeacon-for-android/ http://beekn.net/2014/07/ibeacon-for-android/ The Android iBeacon code used to be on Github but is no longer there. IMO the core "infringement" (if there really is any) is about 10-20 lines of Java that unpacks an iBeacon (major, minor, uuid) from a byte buffer and another bit of Java that aims to map RSSI to Apple's simple model for estimating iBeacon distances. The library did wrap the functionality in a nice background-threaded interface, and their API is distinct from Apple's. On the iPhone, there's a BLE daemon that powers iBeacon and is rather crashy (at least as of iOS8). The Radius Networks solution was clearly distinct. The story would be a textbook example of Apple's legal department hurting open innovation except for the detail that Radius Networks was offering a paid developer product atop the open source offering. (But I doubt they were making much money from it). There are a lot of problems with iBeacon technology: * A lot of people have bluetooth off. The surveys out there have a lot of variance, and you typically have a 50/50 chance that a user with a very modern smartphone will have BLE enabled. * Droid battery usage isn't too bad, but Apple's solution has a distinct advantage because the BLE daemon powering the feature can interop more closely with iOS and eat less CPU. It's really hard to get a consistent experience on both platforms. * To do anything productive with the iBeacon (major, minor, UUID), you probably want to ping a webservice, which will be hard unless you have free wifi or you've made fancy deals with carriers (or Apple). And if there's wifi, you might as well just try to use that as a beacon (ala PayPal's product). * You probably /dont/ want to have iBeacons trigger any sort of immediate advert or notification unless the user has previously opted in to the service. A lot of users are starting to not grant notification and other privs by default. Most users also do NOT like background location stuff. There are definitely user segments that differ, but you'll likely need to do a great deal of customer research to validate using iBeacon. If your app is payments, there's already NFC. If your app is marketing, you might get higher engagement with Augmented Reality or something tied to some other location service (ala Amex & 4sq).

146 points by Rican7 11y ago

ge0rg 11y ago

This is a really interesting idea. iBeacon is way too inflexible in what you can encode in it. I really dislike the decision to make it part of the Play API (as opposed to standard Android), as it ends up not being really open after all. I wish they would also document their packet format. At least they write that they support parallel operation as Eddystone + iBeacon [1], which means that they probably use the BLE "advertisement" frame for the iBeacon and the BLE "scan response" for the Eddystone data. With both frames limited to 29 bytes, there is not much space to toy around. [0] http://developer.radiusnetworks.com/2015/07/14/introducing-eddystone.html http://developer.radiusnetworks.com/2015/07/14/introducing-e... [1] http://altbeacon.github.io/android-beacon-library/eddystone-support.html http://altbeacon.github.io/android-beacon-library/eddystone-...

yresnob 11y ago
isn't the link on their github to the packet format? https://github.com/google/eddystone/blob/master/protocol-specification.md https://github.com/google/eddystone/blob/master/protocol-spe... I love this release Google needed to take a direction there are so many use cases for this sort of micro proximity I cannot wait to see what folks can do without freaking people out over privacy..
tdicola 11y ago
It looks like they've documented the packet format here: https://github.com/google/eddystone https://github.com/google/eddystone For example URLs: https://github.com/google/eddystone/tree/master/eddystone-url https://github.com/google/eddystone/tree/master/eddystone-ur..., UIDs: https://github.com/google/eddystone/tree/master/eddystone-uid https://github.com/google/eddystone/tree/master/eddystone-ui..., and telemetry: https://github.com/google/eddystone/tree/master/eddystone-tlm https://github.com/google/eddystone/tree/master/eddystone-tl...
GauntletWizard 11y ago
Binding things to the Play API has been an unfortunate compromise for Android; their product partners have not been forthcoming on continued device support, so google has had to bundle more and more as an updatable package rather than as part of the core OS. It's a shame that it's been this way, but in the prisoners dilemma of older device support, LG/Samsung/Etc have chosen to rat many, many times, and Google had to do something.
- myko 11y ago
  It would be nice if the bits of Play Services that could be open sourced were open sourced.
  - gress 11y ago
    They could all be open sourced. Google chooses not to open source them in order to control the platform and develop leverage over their partners.
  - GauntletWizard 11y ago
    Bits like this can be and are open sourced; they're just not as usable open sourced, because obviously they're yet another library to grab and install. All the code you need to interface with it seems to exist on github, though not in nearly as pretty a package.
magicalist 11y ago
As others noted, the packet format is documented. But this: > I really dislike the decision to make it part of the Play API (as opposed to standard Android), as it ends up not being really open after all. doesn't really make sense. How do you open source storing data associated with a beacon in the cloud? The beacon is dumb so it's the client program that associates the broadcast with some action. The only way to open source that is to document the format of the beacon broadcast and release tools to let anyone receive them and parse them, after which any action can be taken. Which is exactly what was open sourced. The Play Services support seems to just be that you don't have to do it yourself if you don't want to on Android™ devices, because play services already has support. If they really want this to take off in iOS apps, though, the only real way they can help developers out is by releasing source directly, I believe (the git repo includes an example iOS app[1] but I haven't looked at it yet) [1] https://github.com/google/eddystone/tree/master/tools/ios-eddystone-scanner-sample https://github.com/google/eddystone/tree/master/tools/ios-ed...

ble52 11y ago

Eddystone for dummies: https://www.youtube.com/watch?v=jSDnf4In6QI https://www.youtube.com/watch?v=jSDnf4In6QI

tdicola 11y ago

This looks really cool, in particular the telemetry packet is a nice idea for transmitting sensor data with BLE broadcast packets. Using that you can 'passively' read many nearby sensors without having to connect to them. I've had some similar ideas and played around with doing similar things using a nRF51822 (like a BLE radio + little cortex M0 chip) but ran into a ton of trouble with the BLE API's of various operating systems (like CoreBluetooth on OSX and bluez 5.3 on Linux). In particular most BLE implementations like CoreBluetooth and bluez have a lot of caching and assume that a device's broadcast & advertisement data rarely changes. This causes a ton of trouble when you put frequently changing data in broadcast packets since you can easily get stale or cached data instead of the most recent broadcast. I'd love to know if the Eddystone developers ran into similar issues with their telemetry packets and had any workarounds.

IshKebab 11y ago
This isn't a problem with the BLE implementations. It's in the BLE specification! > Duplicate advertising reports are not required to be sent to the Host. A duplicate advertising report is an advertising report for the same device address while the Link Layer stays in the Scanning State. The advertising data may change; advertising data or scan response data is not considered significant when determining duplicate advertising reports. Advertising really is designed to advertise the presence of a device. It isn't for putting data in - for that you should connect to the device.
- tdicola 11y ago
  I'd argue its an omission or mistake with the spec then. Being able to passively collect sensor data without connecting to a device is very handy as it allows many devices to read data from many local sensors. If they all have to connect to each sensor then there's contention over the connection (only one device can connect to a sensor at a time) and it wastes power to setup and tear down the connection constantly (negating the whole point of BLE). If advertising isn't for putting data then arguably iBeacon, URI Beacon, Eddystone, etc. go against the spirit of the BLE spec.

mindcrime 11y ago

> The name "Eddystone" might sound a little weird, but Google says it's named after the Eddystone Lighthouse in the UK Damnit Google! Naming things after light-houses is our "thing"![1][2][3][4] :-) All joking aside this sounds like a pretty cool project. And anything that helps keep as much IoT infrastructure open-source as possible, is a Good Thing in our book. I'm actually really hoping this catches on and displaces iBeacon as much as possible. [1]: https://github.com/fogbeam/Quoddy/ https://github.com/fogbeam/Quoddy/ [2]: https://github.com/fogbeam/Neddick/ https://github.com/fogbeam/Neddick/ [3]: https://github.com/fogbeam/Heceta/ https://github.com/fogbeam/Heceta/ [4]: https://github.com/fogbeam/Hatteras/ https://github.com/fogbeam/Hatteras/

socceroos 11y ago
Funny the things you stumble across when reading through user comments. Love what you're doing. In your 'travels', have you come across the need to integrate your services with the TechnologyOne line of products? Information insight is a problem the company I work for struggles with immensely.
- mindcrime 11y ago
  I'm not familiar with TechnologyOne's products, but I'll look them up. If you'd like to talk about it offline, feel free to drop me an email. prhodes@fogbeam.com

jackgavigan 11y ago

The problem with Google is that you don't know if any product/service they launch will still be supported in a few years' time, or if the product/engineering team will lose interest and move on to build the next shiny thing.

wstrange 11y ago
This meme is getting tired. Plenty of other companies EOL products.
- jackgavigan 11y ago
  It's not a meme, it's a cliché. And it's a cliché because it's true. Edit: Coincidentally: https://news.ycombinator.com/item?id=9888387 https://news.ycombinator.com/item?id=9888387

binarymax 11y ago

This really needed to happen to help push the physical web forward. Beacons by the suppliers have just been too expensive. Last year at Full Frontal Conf, Scott Jenson said URIBeacons would cost 'a fiver'...but the cheapest I've ever seen has been $15 each (and that's in bulk). Really glad to see this! Hopefully soon I'll be able to buy dozens of these on the cheap for a serious project.

BenSS 11y ago
You can definitely get the hardware for <$15 in bulk if you source it yourself. There's a huge variation in quality though, as with most of the China stuff. If you're willing to deal with the caveats&lock-in of the Gimbal Beacons you can get those for $5. Feel free to hit me with beacon questions, I've got a bunch of varieties sitting on my desk right now.
- eggie5 11y ago
  what are the caveats of Gimbal?
  - BenSS 11y ago
    Shorter range, proprietary setup/configuration process, cycle IDs (crashing some android bluetooth stacks). They really want you to pay for the backend - wouldn't be surprised if they're sold at cost. The batteries don't last as long as advertised either, but that's pretty much been true for all of the devices I've tested.

ignoramous 11y ago

> Google gets the best of both worlds here. As an open source project, Eddystone gets lots of hardware support from vendors, but if developers want to give users the best experience and have an easier time themselves, they have to submit to the walled garden. Eddystone doesn't need to be tied to Google though, and if developers want to use their own cloud solution or client API This is a killer. This isn't really open source at all [0]. Google controls the eco-system, and has most of the other vendors at its mercy (like how they flip search algorithms, give Google products a prominent listing in the search page, blacklist developers/websites etc). More than Search, its the mobile OS and API monopoly that Google is trying to build that's going to hurt even more. I work on AOSP, and I think it is ridiculous that Google owns so much of the eco-system [1] and continues to get praised for being "open" as well; very much like how this article seems to be praising them now. Besides, whatever happened to proposing to a central body and getting stuff standardized (I get that its political and slow, and no ones like slow)? Google works with W3C to get stuff in the HTTP standard [2], with ECMA too [3], but seems to have problem engaging standards body for other things where it has a near monopoly. Not long after Chrome has taken over a large market share, Google would start treating W3C the same, if it hasn't doing been that already [4]. [0] http://techcrunch.com/2009/12/22/google-open-when-convenient/ http://techcrunch.com/2009/12/22/google-open-when-convenient... [1] http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/ http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-... [2] http://www.tomsguide.com/us/google-spdy-http-internet-w3c,news-13990.html http://www.tomsguide.com/us/google-spdy-http-internet-w3c,ne... [3] https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ [4] http://www.neowin.net/news/microsofts-pointer-events-becomes-w3c-standard-google-and-apple-play-hardball http://www.neowin.net/news/microsofts-pointer-events-becomes... /rant /offtopic

dannyr 11y ago
But then people complain that Samsung, HTC, etc changes Android so much that they clamor for Google to control the OS more. Damn if you do, damn if you don't.
- pjc50 11y ago

meatysnapper 11y ago

The pity is that BLE on Android has sucked, horribly badly, consistently. Google needs to have their hardware have a minimum level of support for basic stuff, and then we can talk. In contrast, Apple's BLE implementation is robust and works well for since the iPhone 4S, and reliably on all the newer platforms

derwildemomo 11y ago
This. I'm currently working on my 3rd Android-BLE project and it's incredible how bad those APIs (and of course the vendor's implementations) are. An inconsistent pile of .. well, nothing nice. I don't get why they have no interest in fixing that..
desdiv 11y ago
Could you please elaborate on where the suckiness lies? Was it particular devices, or particular phone manufacturers? Or was it something wrong with the Android BLE APIs?
- meatysnapper 11y ago
  Everywhere possible: 1) Different levels of support on different hardware 2) Doesn't support half the BLE spec (Peripheral) 3) Limited functionality on the Central side, only supported 4 Peripherals last time I checked 5) Buggy in general Just like we don't trust Apple to build cloud services that don't suck, we don't trust Google to build a consistent hardware/OS experience across Android. This is stuff that is not sexy, but it has to be done, and it's exactly what you expect to be done by a company that doesn't have 30+ years in building their own hardware + OS.

polskibus 11y ago

I hope I'll be able to upgrade my Texas Instruments' SensorTag to be Eddystone compatible in the future.

jonlucc 11y ago
Yesterday, I received some HM-10 BLE boards I ordered a bit ago. I hope the firmware will be updated, but I'm not holding my breath.
- guidefreitas 11y ago
  Yeah, same situation here.

IshKebab 11y ago

This still has their weird URL encoding scheme though. To use it you have to own a very short domain on a common TLD. Kind of limiting.

tuyguntn 11y ago

Maybe offtopic, but does anyone here knows how to manufacture iBeacons?

guelo 11y ago

Yea but as long as iPhones are locked down so they can only talk to iBeacons then no other BLE beacon is going anywhere.

choppaface 11y ago

So is the major advantage of Eddystone that Google will implement it and won't sue you for using it in ways they don't like? Eddystone isn't alone; there's AltBeacon, which is also an 'open' alternative: http://altbeacon.org/ http://altbeacon.org/ Though it looks like they might be 'merging' with Eddystone. AltBeacon was born out of Apple giving Radius Networks a cease & desist about a year ago for reverse-engineering the iBeacon protocol and distributing an open-source Android toolkit (with paid enhancements) for iBeacons: http://beekn.net/2014/07/ibeacon-for-android/ http://beekn.net/2014/07/ibeacon-for-android/ The Android iBeacon code used to be on Github but is no longer there. IMO the core "infringement" (if there really is any) is about 10-20 lines of Java that unpacks an iBeacon (major, minor, uuid) from a byte buffer and another bit of Java that aims to map RSSI to Apple's simple model for estimating iBeacon distances. The library did wrap the functionality in a nice background-threaded interface, and their API is distinct from Apple's. On the iPhone, there's a BLE daemon that powers iBeacon and is rather crashy (at least as of iOS8). The Radius Networks solution was clearly distinct. The story would be a textbook example of Apple's legal department hurting open innovation except for the detail that Radius Networks was offering a paid developer product atop the open source offering. (But I doubt they were making much money from it). There are a lot of problems with iBeacon technology: * A lot of people have bluetooth off. The surveys out there have a lot of variance, and you typically have a 50/50 chance that a user with a very modern smartphone will have BLE enabled. * Droid battery usage isn't too bad, but Apple's solution has a distinct advantage because the BLE daemon powering the feature can interop more closely with iOS and eat less CPU. It's really hard to get a consistent experience on both platforms. * To do anything productive with the iBeacon (major, minor, UUID), you probably want to ping a webservice, which will be hard unless you have free wifi or you've made fancy deals with carriers (or Apple). And if there's wifi, you might as well just try to use that as a beacon (ala PayPal's product). * You probably /dont/ want to have iBeacons trigger any sort of immediate advert or notification unless the user has previously opted in to the service. A lot of users are starting to not grant notification and other privs by default. Most users also do NOT like background location stuff. There are definitely user segments that differ, but you'll likely need to do a great deal of customer research to validate using iBeacon. If your app is payments, there's already NFC. If your app is marketing, you might get higher engagement with Augmented Reality or something tied to some other location service (ala Amex & 4sq).