BLE under the microscope. Part 3

BLE under the microscope. Part 3

In the first and second parts, we reviewed the principles of building BLE networks, as well as touched upon the necessary tools for working with them. In the third part we will deal with the practical application of the knowledge gained. For these purposes, we consider this project on the nRF51822 chip from Nordic .

The project implements the transfer of data on advertising channels without using a stack.
In order to run the project, you need the nrf51822 chip on any KIT, the J-LINK programmer, as well as the installed SDK. We unpack the project and place it in the SDK directory, in the folder where the peripherals are located. This is necessary in order not to rewrite the paths to the libraries. Received data can be viewed using the nRF Connect program.


')
Today we will look at how a packet is formed for transmission over BLE channels. The most interesting thing for us is in the ble_radio.c file. I borrowed the function radio_init () in the sniffer program from Nordic-a. This is the most crucial part. Without the correct initialization of the radio channel, we will not see any parcels at all. Every 100 ms the program sends three frames on the air on advertising channels. How parcels are formed, we now consider.

The parcel starts with a header. Depending on the ble_adv_conn flag, our device will be seen as being attached (ADV_IND) or not being connected (ADV_NONCONN_IND). The difference between them was given in the first part. Here I just want to note that in both cases the randon MAC address flag has already been set. If we want to get a public MAC address, then the header byte will be 0x00 and 0x02, respectively. The following is a byte of the length of the entire packet and a service zero byte. I did not understand why it is needed. It is not put on the air, but if it is not there, we will get a byte shift in the package.

This is followed by six bytes of the MAC address and a block of flags. Here you need to specify the general format of the data to be filled. First comes the length byte (LEN), then the content identifier (TYPE), and then the data itself (VALUE). The flag block is the first block of data that we can see in the nRF Connect program.



Next, the device name is recorded. In this case, after the length byte, the identifier is 0x08. It means that this is an abbreviated device name. If you make the identifier equal to 0x09, the name will be seen as full. For us, it does not matter, because we work without a stack and work out all the requests ourselves. In the case of working with the stack, to the request of the phone with the full name, it will be displayed in the response package. Behind the name is a block of factory data and a checksum. It should be noted that the factory data identifier is byte 0xFF, followed by 2 bytes of the manufacturer ID and the data itself. This is the field in which we can transmit any of our data.



Similarly, sending a BLE may contain other data, such as a device UUID or device power (TYPE = 0x0A). View all IDs here . But what this package looks like in Wireshark. We see that this program provides significantly more information for the developer than nRF Connect.



However, this is not all. If we form a package in the format of a beacon (ADV_NONCONN_IND), then it will be received on the phone by a special program. In order for the phone to see the device in the ADV_IND format, it is necessary to correctly process the SCAN_REQ request. As mentioned in the second part for this we must promptly set the answer SCAN_RSP. We can see these packages only with the help of a sniffer. They look like this.



In this case, there is nothing interesting in them. The first (SCAN_REQ), besides the header, contains the MAC addresses of the phone itself and our device. The second (SCAN_RSP) - only the header and MAC address of the gadget. However, the parcel may contain data. As mentioned earlier, this allows you to transfer more information to the phone. In this case, the principle of filling the parcel is similar to what we considered above. The third part devoted to the study of BLE packages has been completed.

Pecherskikh Vladimir

PS If you look closely at the CheckData () function, you can see that it has two parts. It handles both the SCAN_REQ requests (header 0x03) and CONNECT_REQ (header 0x05). This makes it possible not only to receive data on the phone, but also to send one command to the gadget. In this case, the device beeps and blinks the LED. Unfortunately, the team will be only one and will be executed when you try to join the device. Thus, we can, for example, enable / disable a light bulb without installing any applications on your smartphone. This can be done directly from the menu “Settings-> Bluetooth” of the phone.