AltBeacon
altbeacon.org
altbeacon.org
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.
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?
Are there any non-commercial, open source iBeacon-compatiable libraries out there for Android? It would be handy to know if there are.
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).
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.
Do you have examples of organizations or communities that have good answers to your questions?
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.
The short answer is that sitting on a governance board takes time and effort, and mobile developers at large aren't really convinced of the benefit (relative, to, say, the Debian advisory boards).
To overcome this you'd need to recruit from people invested in the problem. Probably your competitors.
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...
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)
And yes, it's a huge barrier to usefulness.
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.
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.
If anyone can get that working please let me know.
Full disclosure: I work for Radius Networks.
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.
However it is really a waste of energy to send 2 types of beacon packets when one should suffice. However it is technically possible.
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.
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.
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
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.
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.