Google’s Eddystone – a flexible, open-source iBeacon alternative
1–10 of 45 posts
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#2This 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...
[1] http://altbeacon.github.io/android-beacon-library/eddystone-...
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#3This 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 "…
isn't the link on their github to the packet format?
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..
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#4Eddystone for dummies: https://www.youtube.com/watch?v=jSDnf4In6QI
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#5This 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 "…
It looks like they've documented the packet format here: https://github.com/google/eddystone For example URLs: https://github.com/google/eddystone/tree/master/eddystone-ur..., UIDs: https://github.com/google/eddystone/tree/master/eddystone-ui..., and telemetry: https://github.com/google/eddystone/tree/master/eddystone-tl...
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#6This 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.
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#7This 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 "…
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.
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#8> 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/
[2]: https://github.com/fogbeam/Neddick/
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#9This 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 "…
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.
Re: Google’s Eddystone – a flexible, open-source iBeacon alternative
#10The 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.