

AltBeacon - bherrup
http://altbeacon.org/

======
xur17
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?

~~~
maxsilver
> 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.
Presumably, Apple will have a harder time being a bad citizen against
AltBeacon.

~~~
alexeckermann
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?

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

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

------
Timmmmbob
But how is iBeacon proprietary anyway? It's just a static BLE advertisment of
a UUID. Anyone can do that.

~~~
justina1
The spec for iBeacon is proprietary and the name is trademarked
([http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4803:h5e...](http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4803:h5eavx.2.1)).

IIRC, Apple even went so far as to revoke iBeacon usage from companies that
tried to make an Android library (Radius Networks, the creators of this spec,
being one of them).

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

~~~
csexton
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?

~~~
brokentone
I don't know that I'm asking questions here, but I don't really understand an
"open source spec" \-- public specs are public, there isn't really source to a
spec.

You're asking for a community RFC on a spec, but have not specified how the
good ideas will come forward, who will be voting on them, etc. If it's just
your company as the "voting party," it's not very open either.

This just leaves the Radius Networks spec for beacons.

------
ChikkaChiChi
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)

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

~~~
ivanca
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)

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

------
josephlord
Does anyone know if this appears as an iBeacon to iOS devices? You can get iOS
devices to listen for other BLE advertisers (or advertise their UUID) in the
background (even after the app is closed due to memory pressure) but I haven't
been able to make it survive a phone reboot.

If anyone can get that working please let me know.

~~~
csexton
AltBeacon will not register as a CoreLocation Beacon on an iOS device.

Full disclosure: I work for Radius Networks.

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

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

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

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

~~~
StarDestroyer
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...](http://nordicsemiconductor.github.io/nRF51-multi-role-conn-
observer-advertiser/).

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

------
azdle
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 returns a JSON blob about that bus stop.

~~~
alexeckermann
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 multiple ways.

Moreover, the UUID is described as a region identifier where, in your
scenario, all the beacons for the bus company would have the same region
identifier but each individual beacon representing a stop would have an
individual major and minor identifier (2-byte each) to uniquely identify that
particular stop. So the way in which the iBeacon spec and somewhat AltBeacon
are authored don't really allow for that kind of implementation because of the
limitations imposed by the small advertising packet space. Its intended that
the identifier space be used for something like a UUID with a set of
supporting identifiers (major, minor).

As you can see from the AltBeacon spec diagram; there is only 28-bytes
available for advertisable data on a Bluetooth Smart peripheral. So there is
not a lot of room to play with.

~~~
azdle
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](http://obcn.io)

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

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

