Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

21–30 of 45 posts

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

#21

Post by dannyr »

ignoramous wrote: post #13

> 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 ope…

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.

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

#23

Post by bitmapbrother »

ignoramous wrote: post #13

> 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 ope…

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

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

#24

Post by GauntletWizard »

myko wrote: post #9
GauntletWizard wrote: post #7

Earlier quoted context omitted.

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…

It would be nice if the bits of Play Services that could be open sourced were open sourced.

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.

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

#25

Post by tdicola »

IshKebab wrote: post #20
tdicola wrote: post #6

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 operat…

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 ad…

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.

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

#26

Post by ignoramous »

bitmapbrother wrote: post #23
ignoramous wrote: post #13

> 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 ope…

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

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.

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

#27

Post by bitmapbrother »

ignoramous wrote: post #26
bitmapbrother wrote: post #23

Earlier quoted context omitted.

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

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,…

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.

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

#28

Post by jonlucc »

polskibus wrote: post #16

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

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.

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

#29

Post by eggie5 »

BenSS wrote: post #17
binarymax wrote: post #12

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.

You can definitely get the hardware for Feel free to hit me with beacon questions, I've got a bunch of varieties sitting on my desk right now.

what are the caveats of Gimbal?

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

#30

Post by magicalist »

ge0rg wrote: post #2

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 "…

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

Post reply on HN