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 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.
I've done quite a lot of thinking about how governance boards could work (or not) for mobile-based projects.
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.
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.
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.
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.
I think these guys had a bunch of ibeacon utilities for ios and osx, as well as detailed docs on the protocol online, but they were recently pulled, at least from homebrew. Did Apple intervene?
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).
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.
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
33 comments
[ 2.9 ms ] story [ 82.2 ms ] threadSo, 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...
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.
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).
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.
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.
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.