Distinguish three concepts: beacon, BLE and iBeacon
BLE
The full name is Bluetooth Low Energy, Bluetooth low power technology. Today's Bluetooth technology consumes very little power. It is not like the rumor that Bluetooth needs to be turned off to save power when not using it. The power consumed by turning on Bluetooth for a long time on a mobile phone is negligible.
beacon
It is used for indoor positioning and is an application scenario implemented based on the BLE protocol with slight changes in broadcast search and changed the data type .
Broadcast search protocol is located in the GAP layer of the standard Bluetooth protocol. Devices communicate with each other through the protocol of this layer.
Therefore, it can be understood that beacon is an application scenario of non-standard BLE because it does not comply with the GAP specification ("Supplement to the Bluetooth Core Specification V6" Part A 14 July 2015) and uses an undefined data type.
iBeacon
It was proposed by Apple as a variant of beacon.
Variants of the same type include:
- apple iBeacon
- Radius Networks ： AltBeacon
- google : Eddystone
iBeacon and BLE in iOS
In iOS, iBeacon is a micro-positioning technology based on geographical location (from this sentence, it can be concluded that Introduced in iOS 7, iBeacon is an exciting technology enabling new location awareness possibilities for apps.), although using mobile phone Bluetooth to receive Majro, Minor , but they have no relationship in the development project.
iBeacon uses the CoreLocation library provided by Apple, whereas BLE uses the CoreBluetooth library during development. It is very clear from the libraries provided above. Especially if you want to use iBeacon on IOS8, you must let the user click whether to allow "App to use geolocation". If there is no prompt when using the ios app to scan iBeacon for the first time, it is impossible to receive the iBeacon signal (unless under ios 8.0). If it is BLE, the user needs to be prompted to turn on Bluetooth during the development process, and no other geographical location information is required.
The difference between iOS and Android in the development process of BLE and iBeacon
- All data in ios is obtained through API, which means that you will not see the naked data of the Bluetooth module in IOS (the naked data here represents the hexadecimal data sent by the Bluetooth module), you can only get to data in very specific APIs provided by Apple.
- ble and ibeacon each use their own API, and there is no correspondence between them. If you want to use ble, it is impossible to obtain the major, minor, uuid and other information of ibeacon. If you use ibeacon, there is no way to initiate a link request to obtain services.
- In ios, ibeacon communication data is only
//设备的唯一ID，一般是自定义；
open var proximityUUID: UUID { get }
//主要区域标识，可定义（例如：xxx商场的标记）；
@NSCopying open var major: NSNumber { get }
//次要区域标识，可定义（例如：xxx商场的xxx店铺）；
@NSCopying open var minor: NSNumber { get }
// 设备的信标距离
open var proximity: CLProximity { get }
// accuracy表示相对距离，是一个float类型数据。
open var accuracy: CLLocationAccuracy { get }
// RSSI就是信号强度。
open var rssi: Int { get }
The respective meanings of these six attributes are:
proximityUUID, major, and minor represent the uuid of iBeacon, major, and minor;
proximity are several attributes provided by Apple that represent distance.
- CLProximityUnknown (no data)
- CLProximityImmediate (within ten centimeters)
- CLProximityNear (within one meter)
- CLProximityFar (one meter away)
In the eyes of many hardware personnel, there is no difference between ibeacon and ble. We are both developed on the same module, but the format of the data sent is different. There should be no difference between ibeacon and ble. iOS can obtain data according to the communication we provide. Just parse the protocol. "
This makes the mistake I just mentioned. In the development process of iOS, ibeacon and ble are two different things. All data is intercepted by Apple, and only specific APIs can be called by developers. Although
from There is no difference from the hardware perspective, but they are indeed two different things during the development process. However, many manufacturers want ble to have similar functions to ibeacon. For example, what should I do if the app can obtain major and minor? Does the ios app obtain the MAC address of ble and other functions (note that ios cannot directly obtain the MAC address of ble)? Here (just my personal opinion and some methods I got at work) are my suggestions, Generally, many BLEs carry "kCBAdvDataServiceData" information when sending discovery broadcasts. You can put the major and minor of ibeacon in the data area of kCBAdvDataServiceData, and then let the app intercept the response information according to the protocol. You can also put it in other information. This It depends on the company's strategy.
If there is an iOS BLE inspection App (non-iBeacon App) that can use BLE to scan iBeacon information, its App is definitely not scanning iBeacon directly. This can be verified from two aspects. First: whether to use the user
’s geography Position,
second : get a standard iBeacon from another manufacturer (the uuid of the iBeacon must not be the same, because iOS must specify the uuid that needs to be scanned when scanning the iBeacon, and it is impossible to scan it with another uuid app).
Through the above two points, you can easily determine whether the app is inspecting BLE or iBeacon.
To sum up all the above points , if you want to use the iOS app to inspect BLE and also inspect iBeacon, you must make a fuss about the broadcast data of the Bluetooth module. How to make a fuss needs to be weighed by each manufacturer.
iBeacon design logic:
iPhone users can receive information broadcast by iBeacon devices (Bluetooth peripheral devices) without opening the App (the App has been opened by the user, authorized to use Bluetooth and positioning, and Bluetooth is on), and the system will briefly activate the App. (about 10 seconds) to execute some methods.
According to the emission range of the iBeacon device, the user's current status is determined: entering, continuing to monitor, and leaving. Then respond differently.
Application scenarios:
Bluetooth scan; regional push; on-site interaction at events (pairing, treasure hunting, etc.); sign-in, Bluetooth lock (manually sign in and unlock within the app or light up the screen to sign in and unlock).