This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
en:iot-open:practical:hardware:sut:esp32:iot_9 [2024/05/01 12:32] – [Start] ktokarz | en:iot-open:practical:hardware:sut:esp32:iot_9 [2024/05/04 09:20] (current) – ktokarz | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
This scenario presents how to extend the Bluetooth Low Energy server and client devices with a notification/ | This scenario presents how to extend the Bluetooth Low Energy server and client devices with a notification/ | ||
===== Prerequisites ===== | ===== Prerequisites ===== | ||
- | It is necessary to understand the principles of the Bluetooth Low Energy protocol with concepts of services, characteristics and descriptors. Notification and indication methods of data transmission should be known. We will use in this scenario the knowledge of the services and characteristics so making the IoT_8 exercise is recommended. | + | It is necessary to understand the principles of the Bluetooth Low Energy protocol with concepts of services, characteristics and descriptors. Notification and indication methods of data transmission should be known. We will use in this scenario the knowledge of the services and characteristics so making the [[en: |
===== Suggested Readings and Knowledge Resources ===== | ===== Suggested Readings and Knowledge Resources ===== | ||
* [[en: | * [[en: | ||
Line 11: | Line 11: | ||
===== Hands-on Lab Scenario ===== | ===== Hands-on Lab Scenario ===== | ||
- | This scenario is intended to be implemented using two BLE laboratory nodes. One of them is a server, while the second is a client. Here we will present the extension of the scenario implemented in IoT_8. | + | This scenario is intended to be implemented using two BLE laboratory nodes. One of them is a server, while the second is a client. Here we will present the extension of the scenario implemented in [[en: |
==== Task to be implemented ==== | ==== Task to be implemented ==== | ||
**Task 1.** Implement a program that operates as the BLE server which advertises itself and allows us to connect to. After a successful connection, it handles the notify descriptor modification and sends the data automatically if notifications are enabled. | **Task 1.** Implement a program that operates as the BLE server which advertises itself and allows us to connect to. After a successful connection, it handles the notify descriptor modification and sends the data automatically if notifications are enabled. | ||
Line 18: | Line 18: | ||
==== Start ==== | ==== Start ==== | ||
- | You can use the simple client and server programs from IoT_8 as the starting point. | + | You can use the simple client and server programs from [[en: |
==== Steps ==== | ==== Steps ==== | ||
- | We will pass through the lab in a few steps. We will add the second characteristic to the example from lab IoT_8. We will configure this characteristic as notify/ | + | We will pass through the lab in a few steps. We will add the second characteristic to the example from lab [[en: |
=== Step 1 === | === Step 1 === | ||
- | We start with the program written during the laboratory IoT_8 by including the BLE2902.h library which handles the Client Characteristic Configuration Descriptor (CCCD). The descriptor of this type is used to enable or disable the notification and indication feature. | + | We start with the program written during the laboratory |
^ Descriptor UUID ^ Bits 1 and 0 ^ CCCD value ^ Function | ^ Descriptor UUID ^ Bits 1 and 0 ^ CCCD value ^ Function | ||
| 0x2902 | | 0x2902 | ||
Line 83: | Line 83: | ||
}; | }; | ||
</ | </ | ||
+ | |||
+ | === Step 3 === | ||
+ | In this step, we'll analyse the communication between the server and the client. The client software is much more complex than the server. Some parts of the client software are implemented as callback functions because they handle reactions on the data coming asynchronously from the server. The diagram presents the algorithm of the client and data coming from the server. | ||
+ | {{ en: | ||
+ | |||
+ | === Step 4 === | ||
+ | We have to extend the client software from scenario [[en: | ||
+ | <code c> | ||
+ | #define REMOTE_NOTIFY_CHARACTERISTIC_UUID " | ||
+ | </ | ||
+ | |||
+ | In the function for connecting to the server, we have to add another characteristic and register the callback function. It is also good to clear the LCD after establishing a connection. | ||
+ | |||
+ | <code c> | ||
+ | // Obtain a reference to the notify characteristic of the chosen service. | ||
+ | pRemoteNotifyCharacteristic = pRemoteService-> | ||
+ | |||
+ | if(pRemoteNotifyCharacteristic-> | ||
+ | pRemoteNotifyCharacteristic-> | ||
+ | | ||
+ | lcd.clear(); | ||
+ | </ | ||
+ | |||
+ | Next, we add the callback function which will be called every time the server sends a new notification packet. | ||
+ | <code c> | ||
+ | static void notifyCallback( | ||
+ | BLERemoteCharacteristic* pBLERemoteNotifyCharacteristic, | ||
+ | uint8_t* pData, | ||
+ | size_t length, | ||
+ | bool isNotify) | ||
+ | { | ||
+ | lcd.setCursor(0, | ||
+ | pData[length]=0; | ||
+ | lcd.print((char*)pData); | ||
+ | } | ||
+ | </ | ||
+ | < | ||
+ | You can leave a periodical reading of the second characteristic in the loop(), but you will observe that sometimes its value appears together with the notification in the first line of the LCD. This is because notification callback is called as the interrupt handler, and can be executed between setting the cursor and displaying the characteristic value. The only way to avoid it is to move displaying of incoming notifications to the mail loop. | ||
+ | </ | ||
+ | |||
+ | |||
==== Result validation ==== | ==== Result validation ==== | ||
- | You should be able to find the device in the BLE neighbourhood. It should allow us to establish a connection, read the characteristic data and write a new value. After enabling the notification we will observe periodic incrementation of the value sent with data packets. | + | You should be able to establish a connection |
+ | < | ||
+ | You can observe that sometimes devices do not connect. This can happen because if you upload the new version of the program to one of the devices the second one remains in a connected state. In such a situation you need to restart both devices. | ||
+ | </ | ||
===== FAQ ===== | ===== FAQ ===== | ||
Line 90: | Line 134: | ||
**What is the difference between notification and indication? | **What is the difference between notification and indication? | ||
- | **Is the notification/ | + | **Is the notification/ |
<WRAP noprint> | <WRAP noprint> |