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

11–20 of 45 posts

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

#11

Post by gress »

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.

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.

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

#12

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

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

#13

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

[1] http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-...

[2] http://www.tomsguide.com/us/google-spdy-http-internet-w3c,ne...

[3] https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

[4] http://www.neowin.net/news/microsofts-pointer-events-becomes...

/rant /offtopic

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

#14

Post by 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

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

#15

Post by wstrange »

jackgavigan wrote: post #10

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.

This meme is getting tired.

Plenty of other companies EOL products.

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

#17

Post by BenSS »

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.

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

#18

Post by derwildemomo »

meatysnapper wrote: post #14

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

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

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

#20

Post by IshKebab »

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

Post reply on HN