AltBeacon • Hacker News Board

Re: AltBeacon

#31

Post by alexeckermann » Tue, Jul 29, 2014, 7:36 AM UTC

lnanek2 wrote: post #30

alexeckermann wrote: post #25

Earlier quoted context omitted.

I haven't been able to find definitive reports of this — I wasn't aware of it when it happened and am piecing together details I can find. If Radius Networks was producing commercial iBeacon products (SDK's) then Apple was within their rights to stop that. To be honest, I think that is fair. I can't imagine this is preventing Android from using iBeacons. My opinion would be that it is preventing profiteering from som…

The RadiusNetworks library for Android was very good, I used it before at some hackathons on Google Glass and it worked great. They had a free version that was great and a pay version with extra features like conserving battery use. There is no chance in the world that Apple killed it because they wanted a freer version for Android. They pretty clearly didn't want any version for Android at all.

I don't agree with that. It may be the case that Android might bake it into the OS and most likely have a trademark agreement with Apple. There is no non-conspiratorial reason why Apple should completely shun iBeacon's on Android. All it will need is respect of the trademark — love them or hate them its the game we have to play at the moment.

Are there any non-commercial, open source iBeacon-compatiable libraries out there for Android? It would be handy to know if there are.

Re: AltBeacon

#32

Post by StarDestroyer » Tue, Jul 29, 2014, 11:12 AM UTC

csexton wrote: post #5

brokentone wrote: post #2

I'm not seeing anything on the community leadership, board, voting etc. The only references I see are to Radius Networks. So, the way I read the mission statement is: We [Radius Networks] firmly believe that an open specification would help everyone, and we [Radius Networks] want to do it right. This is simply the proposal, now we [Radius Networks] would like feedback from the community.

This is something we at Radius Networks are trying to figure out. We've been committed to open source for a while and wanted to get the proposal published -- but are actively researching how to properly establish this spec. Do you have examples of organizations or communities that have good answers to your questions?

I think the answer would be to propose the beacon to be part of the Bluetooth SIG specifications. Any group of 3 companies in good standing in the Bluetooth SIG (adopter or above) can propose this to the SIG. This is called a New Work Proposal. This can then be taken up by a Study group/working group to actually get the specifications adopted by the Bluetooth SIG.

This is the link to the NWP: https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?d... (Requires login and you need to be a Bluetooth SIG member)

Edit: This may be a better link as it shows the dcouments available in the Bluetooth SIG. https://www.bluetooth.org/en-us/specification/reference-publ...

Re: AltBeacon

#33

Post by StarDestroyer » Tue, Jul 29, 2014, 11:51 AM UTC

maxsilver wrote: post #27

alexeckermann wrote: post #23

Earlier quoted context omitted.

Interested to know how you intend to do that with all the advertising space already used up by one of the beacon advertisements?

One option is to alternatively switch between both broadcasts on a single radio. You broadcast a single iBeacon-only message, sleep for a few hundred miliseconds and then broadcast a new AltBeacon message. The beacon does this so quickly, that it's usually sending out two or three of both kind of messages every second. It's effectively an iBeacon + AltBeacon in one device.

You can use this example to send this example code on github to run multiple advertisers. (May be a bit of overkill to just send 2 kinds of beacons but does provide accurate timing control over the beacons). http://nordicsemiconductor.github.io/nRF51-multi-role-conn-o....

However it is really a waste of energy to send 2 types of beacon packets when one should suffice. However it is technically possible.

Re: AltBeacon

#34

Post by sirvon » Sun, Aug 03, 2014, 11:40 AM UTC

matt_kantor wrote: post #28

azdle wrote: post #26

Earlier quoted context omitted.

Yep, I over counted the bytes in the AltBeacon spec, but I still think that a URI-based beacon would be very beneficial. I'm not saying that it needs to fit into the iBeacon or AltBeacon specs, I'm just commenting that I think we'd be much better off with a beaconing protocol that doesn't require some central database controlled by one company. I don't know that much about iBeacon and how the major and minor work, bu…

Nice job taking initiative! Do you know if there's a technical reason for ad packets to be so small? I like the idea of using URIs, but if beacons automatically caused my device send arbitrary network requests along with any kind of identifying information it could be quite scary (someone could track my location in real time by tossing a bunch of cheap beacons around). Also, you'll probably want to cram a URI scheme…

most mobile apps already do that....that being, automatically HTTP POST information about you from your device to various datastores and data crunchers globally. some of our privacy automatically will be made public.