I'm working with a project which involves Bluetooth Low Energy beacons. Super simple schematic will just broadcast an unique number of the beacon. These beacons are used in a warehouse which is about 100 x 100 meters, with possible expand to more and bigger warehouses, and they are used to identify cartons.
We plan that operator will carry iPhone 4s/5, where our small application would scan BLE channels, find our beacons and collect numbers.
However, there is one thing I cannot grasp. There is an Advertising mode in Bluetooth LE specs, with the summary like this: "An advertiser uses the advertising procedure to perform unidirectional broadcasts to devices in the area. The unidirectional broadcast occurs without a connection between the advertising device and the listening devices. The advertising procedure can be used to establish connections with nearby initiating devices or used to provide periodic broadcast of user data to scanning devices listening on the advertising channel. The advertising procedure uses the advertising physical channel for all advertising broadcasts."
So, as far as I understand, we will have to include some header information to help our app differentiate "our" BLE beacons from other BLE advertising devices around. Is it overall possible to just periodically scan the channels and read beacon data? Or is it like "old" Bluetooth so we will have to introduce all beacons to our devices first before it will be possible to read data from them?..
Also I wonder how much beacons would it be possible to read in, say, 10 meter radius in, say, 5-10 seconds?.. There may be about 500 beacons in this radius.
Opinions and suggestions are very welcome. Thanks.
--
The advertisement packet your beacons send can contain custom data. However the space is very limited, around 31 bytes. About 16bytes of it goes to the 128bit "service UUID" of your beacon. The structure of the packet is defined by the bluetooth spec and it does have some overhead, so I'm not sure how much is actually available for the custom data.
The service UUID is an identifier which your iphone app will search for. The idea that each service has a unique identifier, so if an app wants to find heart rate monitors, it will scan for the heart rate monitor uuid. In iOS you can even do a wildcard scan, and it will return any ble advertisements it can find, regardless of the services it has. It is however recommended by Apple guidelines that you specify the service UUID.
There is no requirement for pairing in order to receive the advertisment packets from the beacon. There is also no theoretical limit that would prevent that the beacons couldn't be found, given an infinite amount of time.
I haven't heard anyone putting 500 advertising BLE beacons in the range of an iPhone to see how many it can detect. With 500 beacons advertising simultaneously there will be a lot of collisions between packets. This could theoretically be calculated with knowing the advertisement interval.
The iPhone scan window (how long the channels are actively listened to) and scan interval (how often the scanning window is entered) cannot be adjusted, isn't documented and cannot be relied to remain the same between versions. This means that there isn't a way to really calculate how the advertisements will be found.
There's some recommendations published by Apple about advertising: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
Oh, and by default iOS will filter the results so you get one notification per scan session, per beacon. You can set the "allow duplicates" option in the scan to get multiple notifications per scan session for each beacon if this is needed, but again, apple doesn't recommend it.
If you end up testing this with 500 beacons, or even > 10, I thin a lot of people would be interested in your results. I personally would also appreciate hearing about your experiences.
--
Thank you for the detailed answer. I will definitely update the info when we test the real live beacons. It should be somewhere in late Fall. For now it seems like Apple is targeting their iBeacons to do almost what we want, though we would love some Android compatibility too. :) –
--
I would say that it is unlikely that the iBeacons would be fundamentally incompatible with Android, as from what I understand it is going to be just based on standard BLE technology. Unfortunately there isn't currently enough information to create iBeacons, and the iBeacons are more about regions than anything else. –
--
A BLE advertisement packet only takes up some 300-400 micro seconds pr channel (I checked one packet and it took 296us). So ideally there should room for some 2500 packets pr second. Given this, it should be possible with more than 500 beacons in one area if you configure them to advertise only say once pr second. They should still be fairly quick to find and the built in randomness in the protocol should to some degree mitigate devices that collide by chance. –
--
댓글 없음:
댓글 쓰기