1) The good news is that the SDK is able to detect beacons from all manufacturers - I tried KS technologies, Qualcomm, TI
2) The bad news is that BLE technology itself does NOT specify a protocol for advert data transmitted by beacons. This means that there is no standard way of getting UUID, MajorId, MinorId across all manufacturers. Each manufacturer sends this data in a byte array and the order of bytes is not the same.
3) The only reason we really need UUID, MajorId, MinorId is so that we can uniquely identify a beacon and implement our application logic based on that. I tried using the MAC address of the beacon as unique key but that doesn't work because Qualcomm (and maybe others) rotate the advertised MAC address several times in a second because of which it's not unique.
4) This is where Apple's "iBeacon" spec comes in handy. If the device is compatible with iBeacon spec, it must advertise its data per iBeacon spec. If that is the case, then parsing beacon attributes like UUID, MajorId, MinorId is simple.
5) If we do not enforce the "iBeacon" requirement then we will need to investigate and find out the way of getting UUID and other advert data individually per manufacturer which won't result in a good user experience since they might use a beacon from a manufacturer which is not supported by us.
In the light of above findings, I think we should support only "iBeacon" compatible devices. Most beacon manufacturers allow you to configure the device to be iBeacon compatible using some sort of app provided by them. I looked at Qualcomm and TI and both have provided some documentation for that.
Let me know if you guys have any additional thoughts on this. All the code written so far for this investigation is checked into our Git repo and the app is in working state. After you signup and login, it shows you a list of nearby beacons.
1) The good news is that the SDK is able to detect beacons from all manufacturers - I tried KS technologies, Qualcomm, TI
2) The bad news is that BLE technology itself does NOT specify a protocol for advert data transmitted by beacons. This means that there is no standard way of getting UUID, MajorId, MinorId across all manufacturers. Each manufacturer sends this data in a byte array and the order of bytes is not the same.
3) The only reason we really need UUID, MajorId, MinorId is so that we can uniquely identify a beacon and implement our application logic based on that. I tried using the MAC address of the beacon as unique key but that doesn't work because Qualcomm (and maybe others) rotate the advertised MAC address several times in a second because of which it's not unique.
4) This is where Apple's "iBeacon" spec comes in handy. If the device is compatible with iBeacon spec, it must advertise its data per iBeacon spec. If that is the case, then parsing beacon attributes like UUID, MajorId, MinorId is simple.
5) If we do not enforce the "iBeacon" requirement then we will need to investigate and find out the way of getting UUID and other advert data individually per manufacturer which won't result in a good user experience since they might use a beacon from a manufacturer which is not supported by us.
In the light of above findings, I think we should support only "iBeacon" compatible devices. Most beacon manufacturers allow you to configure the device to be iBeacon compatible using some sort of app provided by them. I looked at Qualcomm and TI and both have provided some documentation for that.
Let me know if you guys have any additional thoughts on this. All the code written so far for this investigation is checked into our Git repo and the app is in working state. After you signup and login, it shows you a list of nearby beacons.