BLE under the microscope 2

BLE under the microscope. Part 2

part 3
In the first part, we analyzed why the Bluetooth LE standard was invented, and also considered the format of advertising packages “advertising”. In this part, we will continue to study the features of the format and consider the mechanism for attaching a BLE device to a smartphone.

BLE Modes

First we will talk about the different modes of operation of BLE devices. Let's start with the simplest. For unidirectional data transfer, for example, from a street thermometer to a telephone, there is a beacon format. The device transmits static or slowly changing dynamic data on the air. Here, users are cautioned by the pitfall. If you scan the broadcast using the menu item android (Settings => BlueTooth), we will not see the beacons. It's all about the type of scan. There is an active and passive scan. Passive scanning simply listens to the broadcast, and with active scanning, an additional request is made to the BLE device. There is a fundamental difference in the mode of operation of the advertisers.

Lighthouses have the header ADV_NONCONN_IND. This means that they are not attached and do not carry additional information, except for the one that is already contained in the package. Due to the fact that they have no additional functions and reception mode, all the energy goes only to the transmission of advertising packages. This is the most economical type of operation for BLE devices. However, in order to see them, you need to use a special program on your smartphone with passive scanning mode. In principle, the information in the beacon package may vary. For example, you need to transfer more information than it holds for one packet. Then a cyclic change of information that the lighthouse transmits is possible.
')
Features passive scanning is that all the data that the android receives from the beacon package, it immediately transmits to the user application. With active scanning, the application will not see the BLE device until the gadget responds to the scan request from the smartphone. This is the most common mode of operation of devices. Consider its features. When scanning, when a smartphone receives a message from a device (such as ADV_IND or ADV_SCAN_IND) on one of the ad channels, it sends a request on the same channel. This is an empty SCAN_REQ command.



It must be transmitted no later than the time T_IFS (Time Inter Frame Space), which is 150 μs. In order for the ad unit to hear this request, after each advertising message it is delayed on the channel for the time T_IFS. At the same time, naturally, additional energy is consumed. If the request is received, the device responds with a send SCAN_RSP. The figure shows that the maximum response delay time is also T_IFS.

And here users are waiting for another pitfall. The fact is that the operating system of the smartphone, after receiving the response command SCAN_RSP, remembers the parameters of the device. She continues from time to time to repeat her SCAN_REQ requests to the gadget, but they are not regular. And at the request of the user application, the system will issue the latest data, regardless of the application needs. Therefore, in order to update the data, for example, from the position sensor, it will be necessary to restart the scanning process on the phone. Therefore, devices with the ADV_IND and ADV_SCAN_IND header are poorly suited for transmitting rapidly changing data in a beacon mode. It is better to go through the joining procedure and switch to the working channels. This will be discussed below, but we will immediately indicate that only ADV_IND devices can do this.

At the end of the chapter I want to make out an interesting feature of the SCAN_REQ and SCAN_RSP commands. The fact is that the response command SCAN_RSP can be either empty or contain any useful information. This is used in two cases. First, when all the necessary information does not fit into one package. Secondly, when they want to save battery energy. This is done like this. The advertising package itself is as short as possible. It includes only the header, flags and MAC address of the device. And when SCAN_REQ is requested, the device sends all additional information about itself (for example, name, battery level, etc.) already in frame SCAN_RSP. The operating system on the phone stitches all the information in one unit.

Joining mode

In order to fully utilize all the resources of the BLE protocol, it is necessary to work at working frequencies. This is a synchronous mode of operation. Consider how to create it. After the smartphone, in response to the request with the active scan, receives the frame SCAN_RSP, it becomes possible to attach the gadget to the phone. The connection process is usually started by the user, but can also be started by the application if the connection is broken. It was for the sake of synchronous mode that BLE was created. After the connection, both the gadget and the phone go into an economical mode. Devices cease to transmit on advertising frequencies, and begin to work on the other 37 channels. Consider how this happens. Take a look at the picture.



In response to the user's request to attach the gadget, the android sends the CONNECT_REQ packet. It must be sent no later than T_IFS wait time. This package contains complete information on which frequencies, with which interval and with which Access Address the smartphone offers to exchange data. Here is the data format of this package.



How it looks in Wireshark is shown in the following figure. In the Link Layer Data section, we see that the new Access Address is 0x21431df6. Next come three bytes of the checksum 0x277d0f. To get the following four time parameters, they must be multiplied by the corresponding coefficient.

transmitWindowSize = Win-Size * 1.25 ms
transmitWindowOffset = WinOffset * 1.25 ms
connInterval = Interval * 1.25 ms
connSupervisionTimeout = Timeout * 10 ms

The ChM part describes those working channels on which further work is expected. And in the part of Hop - at what interval the allowed channels will be moved. According to the specification, Hop is in the range from 5 to 16.



The following figure schematically shows the mechanism for switching to operating frequencies.



Further, the smartphone and the device begin to work in synchronous mode at operating frequencies. However, the smartphone (Master) can change the operating parameters of the gadget (Slave) at operating frequencies. This most often happens when another device joins the phone. To save energy, the smartphone is easier to build work with the attached devices in order to serve them consistently in one waking session. In this case, the Feature Exchange Procedure is used. It is in many ways similar to the accession procedure and occurs automatically, so we will not consider it.

In the conclusion of the chapter, we will slightly touch on the topic of profiles. In order to systematize the transmission and reception of data, services were entered into the BLE format. These are the various tasks that the device can perform. The service, for example, is the ability to report the battery voltage level, or reprogram the device over the air. Profile, as a rule, combines several services. A complete list of BLE device profiles can be found here .

To develop your own devices, the easiest way is to use the NUS (Nordic UART Service) profile. To work with him, nordic-a has two applications. One is the nRF UART 2.0. Another, and in my opinion more convenient, part of the nRF Toolbox.



In this application there is a field of 9 cells, each of which can be assigned to any command, and on the cell itself to hang the icon. Thus, you can get a ready-made remote control for controlling BLE devices. For example, to control electronic toys.

Work with nRFgoStudio

Nordic has a universal tool for working with various whales - this is the nRFgoStudio program. She, like others, can be downloaded on the manufacturer's website here . Connect your device or kit using the programmer to the computer. Open nRFgoStudio and click on the nRF5x Programming line. If the programmer sees the processor, a window will open as shown.



On the right side we see a window with three tabs: Program SoftDevise, Program Application, Program Bootloader. The first window (Program SoftDevise) allows you to load the stack from Nordic-a into the processor, the second - the user application, and the third - the loader over the air (DFU). The site has an article where it was already briefly covered.

Conclusion

I would like to note that we did not analyze in detail the advertising package advertising itself and the method of its formation. Those who are interested in how to do it with pens, I refer to the article . It indicates how you can try to work on a simpler Nordic chip nRF24L01, without using the stack. This will allow a deeper understanding of the structure of the premise.

In addition, you can learn to form these same packages, bypassing the stack, and on the nRF51822 b nRF52832 microcircuits. This is much easier than working with a stack. However, without the stack, we will not be able to work on working channels. Self-implement synchronous mode will be very difficult. The BLE theme is very extensive and constantly evolving. Therefore, we certainly could not describe all the features of this protocol. But for the initial start of this information is more than enough. Additional information can be found here , here and here .

Pecherskikh Vladimir