
Google’s Eddystone – a flexible, open-source iBeacon alternative - Rican7
http://arstechnica.com/gadgets/2015/07/meet-googles-eddystone-a-flexible-open-source-ibeacon-fighter/
======
ge0rg
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-e...](http://developer.radiusnetworks.com/2015/07/14/introducing-
eddystone.html)

[1] [http://altbeacon.github.io/android-beacon-
library/eddystone-...](http://altbeacon.github.io/android-beacon-
library/eddystone-support.html)

~~~
GauntletWizard
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
It would be nice if the bits of Play Services that could be open sourced were
open sourced.

~~~
GauntletWizard
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.

------
mindcrime
> 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
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
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

------
tdicola
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
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
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.

------
meatysnapper
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

~~~
desdiv
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
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.

------
ble52
Eddystone for dummies:
[https://www.youtube.com/watch?v=jSDnf4In6QI](https://www.youtube.com/watch?v=jSDnf4In6QI)

------
ignoramous
> _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-...](http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-
controlling-open-source-by-any-means-necessary/)

[2] [http://www.tomsguide.com/us/google-spdy-http-
internet-w3c,ne...](http://www.tomsguide.com/us/google-spdy-http-
internet-w3c,news-13990.html)

[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...](http://www.neowin.net/news/microsofts-pointer-events-
becomes-w3c-standard-google-and-apple-play-hardball)

 _/ rant /offtopic_

~~~
bitmapbrother
>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.

They own so much of the ecosystem because they produce 99% of the code. It
continues to amaze me how ungrateful people are to Google and their AOSP
project considering they're the ones spending millions on R&D each year, yet
that still isn't enough for the vocal pro RMS minority.

~~~
ignoramous
So are countless other companies (Mozilla, Segment, Facebook, Netflix) and
individual developers open sourcing their code the right way unlike Google
which seems to be using that as either to gather community consensus or to
attract businesses (Hey! You're not tied to us, just roll your own Google Play
Store equivalent, and replicate Google Play Services, and you're done, its all
too easy, and if you don't trust us, fork the project, its all open source!
But you know what... if you don't sign the OHA we'd not provide any support,
and if you do sign the OHA, then you must install our closed source apps).

If you worked with AOSP, you'd rather be more frustrated than grateful. Google
is getting a lot of the bugs fixed for free! And its model has none of the
downsides. Mind you, Google doesn't develop AOSP in the open. It releases
source drops every other month or so, I think. There's a rumour that their
internal branch and one that's open sourced isn't the same. If you'd recall,
Google refused to release code for Android for Tablets (honeycomb) at all. So
that's there too.

~~~
bitmapbrother
What part of Google's AOSP do you disagree with? Is it that they don't perform
every single commit in public or is it that their services aren't open
sourced? As for your reference to the Google Play Store - this makes no sense
at all. It's a service hosted and maintained on Google servers. Did you really
expect Google to give this service away to any competitor that decides to fork
Android?

>But you know what... if you don't sign the OHA we'd not provide any support,
and if you do sign the OHA, then you must install our closed source apps).

Why would Google support a version of Android that refuses to pass the CTS? Do
you really think Google would allow a device to use their services that was
incompatible with Android? Also, why else would a company join the OHA other
than to get the Google Apps and Services?

>If you'd recall, Google refused to release code for Android for Tablets
(honeycomb) at all.

The code wasn't in a state to be released as it was incomplete. When they
pushed ICS out they also included the Honeycomb source. So, it was released
eventually.

>Google is getting a lot of the bugs fixed for free!

Would you by chance know the percentage of bugs fixed by people not employed
by Google? I'm going to guess that percentage is very very low.

~~~
ignoramous
There's no real collaboration with external parties as far as I am aware ala
the Node Foundation, the Linux Foundation etc;

And even if a device passes CTS, Google would not automagically hand you the
keys to the Google Play Services kingdom.

As for Play Store / Play Services is concerned, they've been moving a lot of
code to closed-sourced APKs. For instance, the default browser was open
source, now the default browser that's Chrome isn't. The default keyboard was,
now it isn't. The Camera app was, now it isn't. They started out being more
open than where they are now. And that's my beef with AOSP.

I don't have the count of number of bugs non-Google employees fix. The
percentages may be negligible, but the impact is high-- They do seem to be
looking at mods elsewhere (swipe to dismiss notification? battery percentage
in the status bar? open apps from lockscreen? CyanogenMod had them first), and
they did just brought in Knox from Samsung recently.

Also, I am not asking for free Play Store support, no sir; I am asking for an
open and standardized integration of multiple appstores and related services.
But I guess that's not possible (see first line), and elaborate hacks such as
MicroG need to be put in place
[https://github.com/microg](https://github.com/microg) (a loosing battle,
IMO).

~~~
Oletros
> And even if a device passes CTS, Google would not automagically hand you the
> keys to the Google Play Services kingdom.

Why they should give it? CTS has nothing to do with Play Services

~~~
ignoramous
I know. It was in response to what the other fellow HNer commented: "Why would
Google support a version of Android that refuses to pass the CTS? Do you
really think Google would allow a device to use their services that was
incompatible with Android"

------
binarymax
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
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
what are the caveats of Gimbal?

~~~
BenSS
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.

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

------
IshKebab
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.

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

~~~
jonlucc
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
Yeah, same situation here.

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

------
choppaface
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).

------
jackgavigan
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
This meme is getting tired.

Plenty of other companies EOL products.

~~~
jackgavigan
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)

