Analysis and application of key technologies of BLE low-power Bluetooth

fish001

Analysis and application of key technologies of BLE low-power Bluetooth [Copy link]

1. The transmission distance of traditional Bluetooth ranges from tens of meters to hundreds of meters, while BLE is specified as 100 meters (actually not that far, it is relatively stable within 50 meters, which is related to the transmission power of the device) 2. In order to achieve extremely low power consumption, the BLE protocol is designed to completely turn off the radio frequency in the air when it is not necessary (you can quickly establish a connection for control operations when needed). Compared with traditional Bluetooth BR\EDR, BLE has three major features to achieve low power consumption: shorten the wireless startup time, quickly establish a connection, and reduce the peak power consumption of sending and receiving (determined by the chip). 3. The first trick to shorten the wireless startup time is to use only 3 "advertising" channels (the rest of the channels are used for data transmission), and the second trick is to reduce the working cycle by optimizing the protocol stack. A device in advertising can automatically establish a connection with a device in searching, so the connection establishment and data transmission can be completed within 3ms. (In fact, the first connection is not that fast because some initial configuration is required) 4. Low-power design will bring some sacrifices, for example: audio data cannot be transmitted through BLE. BLE is still a very robust technology. It still supports frequency hopping (37 data channels) and uses an improved GFSK modulation method to improve link stability. BLE is still a very secure technology because it provides 128-bit AES encryption at the chip level (which saves a lot of work in security for application layer development). 5. The Android BLE standard was released on July 24, 2013. Generally, mobile phones with Android 4.3 and above support Bluetooth 4.0 (BLE). Smartphones and tablets will have dual-mode Bluetooth baseband and protocol stacks, which include GATT and all parts below, but no specific protocols above GATT. Therefore, these specific protocols need to be implemented in the application, and the implementation needs to be based on various GATT API sets. This is conducive to simply implementing specific protocols on the smartphone side, and it is also possible to simply develop a set of private protocols based on GATT on the smartphone side. 6. BLE protocol stack PHY layer: 1Mbps adaptive frequency hopping GFSK (Gaussian frequency shift keying), running in the unlicensed 2.4GHz frequency band. Link layer (LL): Controls the status of the device. A device may have 5 states: standby, advertising, scanning, initiating and connected. A device in a connected state will have a role: master and slave. The one who initiates the connection is the master, and the one who accepts the connection request is the slave (usually a mobile phone or tablet acts as the master). Host Control Layer (HCI) ): Provides some methods for communication between the host and the controller through a standard interface. This layer can implement device control through a software API or hardware interfaces such as UART, SPI and USB. Logical Link Control and Adaptation Protocol L2CAP layer: Provides data encapsulation services for the upper layer, allowing logical end-to-end data communication. Security Management Layer SM: Provides pairing and key distribution services to achieve secure connections and data exchange. General Access Profile GAP layer: An interface that communicates directly with applications or profiles, handling device discovery and connection-related services. It also handles the initialization of security features. Attribute Protocol Layer (ATT) ): The ATT protocol allows a device to display some data, which is called "Attribute" to other devices. In ATT, the device that displays these attributes is called server, and the other equivalent device is called client. The states of the LL layer, master and slave, are independent of the two states of the ATT layer. Generic Attribute Profile (GATT) ): It is a service framework that defines the subroutines of ATT applications. GATT specifies the structure of the profile. In BLE, all types of data used by a profile or service are called characteristics. Data exchanged between two devices over a BLE connection must be processed by GATT subroutines. Therefore, apps and profiles will use GATT directly. 7. Generic Attribute Profile (GATT) GATT defines two roles: server and client. GATT roles are not necessarily associated with specific GAP roles, but may be specified by higher-level profiles. GATT and ATT are not transport-specific and can also be used for BR/EDR and low energy. However, since GATT and ATT are used as discovery services, they must be implemented in low energy technologies. 8. GATT Profile Hierarchy The highest level of this hierarchy is the profile. A profile consists of one or more services required to implement a use case. A service consists of characteristics or references to other services. Each characteristic includes a value and may also include optional information about the value. Services, characteristics, and the components of characteristics (i.e., values and descriptors) contain profile data and are all stored in the server's attributes. 9. Device Role Division In the BLE protocol, there are two roles, peripheral and central. The peripheral is the data provider and the central is the data user/processor. In the iOS SDK, an iOS device can be used as a peripheral or a central. However, in the Android SDK, until the latest Android 4.4.2. Android phones can only use and process data as a central. A central can connect to multiple peripherals at the same time, but a peripheral can only connect to one central at a time. BluetoothGattServer acts as a peripheral to provide data; BluetoothGattServerCallback returns the status of the peripheral. BluetoothGatt acts as a central to use and process data; BluetoothGattCallback returns the status of the central and the data provided by the peripheral. A Ble device can only play one role at a time. Each peripheral BluetoothGattServer contains multiple services, each service contains multiple characteristics, and each characteristic contains multiple descriptors. 10. In order to obtain the central BluetoothGatt, the following process is roughly required: Obtain BluetoothManager: mBluetoothManager = (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE); Get BluetoothAdapter: mBluetoothAdapter = mBluetoothManager.getAdapter(); Scan Ble device: mBluetoothAdapter.startLeScan( BluetoothAdapter. LeScanCallback); Get BluetoothDevice from LeScanCallback: public void onLeScan(BluetoothDevice device, int rssi, byte[] scanRecord){.....} Use BluetoothDevice to get BluetoothGatt: gatt = device.connectGatt(this, true, gattCallback); After getting BluetoothGatt, you can interact with the surrounding BluetoothGattServer through BluetoothGattCallback by calling BluetoothGatt methods. App Implementation Process There is a BLE Sample on the Android official website, so I will not paste the code there. 1. First, check whether the device supports BLE. If it does, turn on Bluetooth and get the initialized Bluetooth adapter: 2. After ensuring that BLE is available and Bluetooth is turned on, start scanning for peripheral devices. The scanning process is monitored by the callback interface. Once a peripheral BLE device is found, it will be added to the BLE device list. 3. After clicking on a searched device, it will try to connect to it. At the same time, the device address is put into the broadcast, and finally passed as an input parameter to BluetoothAdapter.getRemoteDevice to obtain the peripheral device. 4. After successfully connecting to the peripheral device, a BluetoothDevice device will be returned. This return value represents the peripheral device connected to the mobile phone. By using the connectGatt(Context context,boolean autoConnect, BluetoothGattCallback callback) method of the peripheral device, you can get the BluetoothGatt instance. The BluetoothGatt class is a public API related to the Bluetooth GATT profile. It provides Bluetooth GATT functions to ensure communication with BLE devices. It can be used to manage client operations (reconnect/disconnect, discover/acquire services, read/write characteristics and descriptions, etc.). BluetoothGattCallback is a callback interface during the connection process, responding to various state changes during the connection process (changes in connection status, discovery of services, reading and writing characteristics (Characteristic), reading and writing descriptions (Descriptor), and changes in the Value of characteristics), reflecting the application of the observer design pattern. 5. After the connection is successful, onConnectionStateChange in BluetoothGattCallback is triggered, so we can use the obtained BluetoothGatt instance to perform operations in this function. The first thing to do after the connection is established may be to search for available services provided by the peripheral device, so we can use the discoverServices() method of the BluetoothGatt instance. At the same time, once the service is discovered, onServicesDiscovered will be triggered. 6. During the connection process, if the connection status changes, onConnectionStateChange(BluetoothGatt gatt, int status,int newState), so we can determine the type of the new state in this function and then perform the corresponding operation. If the connection is disconnected, we only need to add connectBle(mBluetoothDeviceAddress) again in this function to automatically try to connect. 7. In the connected state, if you want to read the value of a Characteristic, you must first call the readCharacteristic(characteristic) method of BluetoothGatt, and then trigger the onCharacteristicRead(BluetoothGatt gatt,BluetoothGattCharacteristic characteristic, intstatus) function, in which you can call the characteristic.getValue() method to get the Value of the Characteristic. 8. Generally, the Value obtained is a byte array. How to parse this Value format depends on the agreement between you and the hardware engineer who developed the peripheral Ble device. The data type passed from the bottom layer is octal, hexadecimal or other types. Based on the data type and the composition of the Value, you can parse out the fields you need.