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

AltBeacon

altbeacon.org

Post reply on HN
Print view View original

21–30 of 34 posts

Re: AltBeacon

#21

Post by alexeckermann »

ChikkaChiChi wrote: post #9

The biggest problem with Beacons is that the range is unpredictable. Without a better handle on proximity, many of the use cases I can immediately think of are of no greater benefit than GPS or WiFi nodes. It's a shame, because there are some amazing things you can do once you are able to start exchanging data based on passing a node by (< 3 meters)

This is entirely dependant on the beacon antenna design and its configuration. I have tested various beacons and have found that beacons using ceramic chip antennas do give these wild and unpredictable ranging values where as a trace antenna, especially the ones provided by TI, are exceptionally good once configured with correct TX power settings.

Using Apple's devices as iBeacons are very accurate. I usually have an margin of error in the region of +/- 10cm at its worst.

But the point of beacons is that they represent a physical thing. "A thing is here. Have its identifier" rather than using GPS or a-GPS to resolve a 2D coordinate that then needs geospatial querying to find an object "closest" to that reported position. No matter how good 2D coordinates are if the thing doesn't stay in one spot or if the accuracy is not great (indoors) then its just a guessing game.

Re: AltBeacon

#22

Post by ivanca »

venus wrote: post #18
ChikkaChiChi wrote: post #9

The biggest problem with Beacons is that the range is unpredictable. Without a better handle on proximity, many of the use cases I can immediately think of are of no greater benefit than GPS or WiFi nodes. It's a shame, because there are some amazing things you can do once you are able to start exchanging data based on passing a node by (< 3 meters)

Why is this being downvoted? It's exactly right. The distance to beacons is extremely unpredictable. Just holding the phone or a beacon in your hand slightly differently is often enough to make the estimated distance change by 10m. And yes, it's a huge barrier to usefulness.

It seems like a very easy problem to solve, why don't the beacons broadcast their locations? (latitude and longitude, then just subtract the GPS location)

Re: AltBeacon

#23

Post by alexeckermann »

csexton wrote: post #14
rodh257 wrote: post #12

Earlier quoted context omitted.

So how do I deal with supporting both Android and iOS from a single Beacon?

I believe the easiest approach would be to broadcast both formats.

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

Re: AltBeacon

#24

Post by alexeckermann »

ivanca wrote: post #22
venus wrote: post #18

Earlier quoted context omitted.

Why is this being downvoted? It's exactly right. The distance to beacons is extremely unpredictable. Just holding the phone or a beacon in your hand slightly differently is often enough to make the estimated distance change by 10m. And yes, it's a huge barrier to usefulness.

It seems like a very easy problem to solve, why don't the beacons broadcast their locations? (latitude and longitude, then just subtract the GPS location)

If the thing the beacon is attached to moves the co-ordinates would need to update and would not be of use because its just GPS. Static beacons are useful where GPS resolution isn't great (concrete canyons), in buildings/structures or an area where theres a high density of beacons that GPS can't resolve quickly or finely enough.

A beacon represents a thing and not a fixed location. A beacon on a vehicle would say "hi I'm vehicle ABC123…" rather than trying to find that vehicle by 2D geospatial resolve from a GPS fix referencing a known database of last locations of vehicles.

Re: AltBeacon

#25

Post by alexeckermann »

maxsilver wrote: post #13
xur17 wrote: post #8

It would appear that iBeacons just broadcast a uuid that clients can discover, and then clients are able to lookup the location of the device from a database. I don't have in depth knowledge of iBeacons, but after skimming the spec, it would appear that this does the same thing, so I feel like I am missing something. How does this differ?

> How does this differ? Fundamentally, it doesn't. AltBeacon (as far as I can tell) exists simply so Apple has a harder time using their bullying legal tactics against people. Specifically, the folks behind AltBeacon (RadiusNetworks) previously made an open source Android library that allowed Android apps to easily detect and use iBeacons. Apple threw their lawyers on them, and they pulled the Android library. Presum…

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 something Apple a) has a trademark on and b) might want available for free.

I assume AltBeacon is the fallout from this. It would be nice if Radius and Apple could work together on Android support. Could be likely that its happening in Android OS already?

Re: AltBeacon

#26

Post by azdle »

alexeckermann wrote: post #20
azdle wrote: post #19

Can anyone explain why a random beacon ID is better than just using something like a URL? That would provide not only uniqueness with an existing and fair registry, but also an implicit way of getting basically unlimited information about a beacon. You stick a beacon on a bus stop sign that broadcasts "mt.obcn.org/XXXXXXXXXX" where MetroTransit owns mt.obcn.io and XXXXXXXXXX is the bus stop id and querying that URL r…

Simple answer: Available advertising space. The identifier field in the iBeacon spec is a 16-byte UUID and no longer than that, AltBeacon has a 20-byte space but its because it includes an unstructured major, minor (compared to iBeacon). If your example was to be represented it would be 22-byte in length which is outside the bounds available — granted that I took the number of X literally and could be shortened multi…

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, but something similar could work by using a aa.bbb.cc/xxx/yyy type of URL. Sure you're wasting 2-4 bytes on the slashes and dots, but I think that would be worth it to have it be a completely open protocol.

Something you should know about me, I'm overly excitable. I've decided that we need to develop one universal standard that covers everyone's use cases. I'm going to create OpenBeacon! http://obcn.io

Re: AltBeacon

#27

Post by maxsilver »

alexeckermann wrote: post #23
csexton wrote: post #14

Earlier quoted context omitted.

I believe the easiest approach would be to broadcast both formats.

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.

Re: AltBeacon

#28

Post by matt_kantor »

azdle wrote: post #26
alexeckermann wrote: post #20

Earlier quoted context omitted.

Simple answer: Available advertising space. The identifier field in the iBeacon spec is a 16-byte UUID and no longer than that, AltBeacon has a 20-byte space but its because it includes an unstructured major, minor (compared to iBeacon). If your example was to be represented it would be 22-byte in length which is outside the bounds available — granted that I took the number of X literally and could be shortened multi…

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

Re: AltBeacon

#29

Post by azdle »

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…

I know what you mean about the tracking and that's actually part of the reason I think this method makes more sense. Something that's been in my head, but not put down anywhere is the idea of applications registering domains. Which to my understanding is similar to how other beaconing works, where UUIDs are registered.

Although there is only so much that you can do to prevent it. I'm kinda mulling around the thought of one basic (anonymous, except IP) request to the base domain for general information about the endpoint and if these implement some sort if well-known action types (transit-stop, point-of-interest, ???) then you'd be able to allow requests to always be made on a domain-by-domain basis or maybe some sort of "tap-for-info" button when you're near something interesting. Not sure yet, but I am generally trying to keep privacy in mind.

EDIT: Missed the part about the advertising packets. I don't really know, I've only read through the BT4 spec really quickly, but I have to imagine it has to do with both not congesting the spectrum with overly verbose broadcast messages and limiting power usage.

Re: AltBeacon

#30

Post by lnanek2 »

alexeckermann wrote: post #25
maxsilver wrote: post #13

Earlier quoted context omitted.

> How does this differ? Fundamentally, it doesn't. AltBeacon (as far as I can tell) exists simply so Apple has a harder time using their bullying legal tactics against people. Specifically, the folks behind AltBeacon (RadiusNetworks) previously made an open source Android library that allowed Android apps to easily detect and use iBeacons. Apple threw their lawyers on them, and they pulled the Android library. Presum…

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.
Post reply on HN