Differences
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_7 [2024/04/14 10:03] – ktokarz | en:iot-open:practical:hardware:sut:esp32:iot_7 [2024/05/02 11:11] (current) – [IOT7: BLE Beacon] ktokarz | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== | + | ====== |
| This scenario presents how to create the Bluetooth Low Energy beacon device which periodically broadcasts a small amount of information, | This scenario presents how to create the Bluetooth Low Energy beacon device which periodically broadcasts a small amount of information, | ||
| Line 20: | Line 20: | ||
| This scenario is intended to be implemented using two laboratory nodes. One node will work as the beacon device, while the second will receive the beacon' | This scenario is intended to be implemented using two laboratory nodes. One node will work as the beacon device, while the second will receive the beacon' | ||
| ==== Task to be implemented ==== | ==== Task to be implemented ==== | ||
| - | **Task 1** Implement a program that operates as the BLE beacon which advertises itself with the link to the SUT website. This can be done with the Eddystone beacon format. | + | **Task 1** Implement a program that operates as the BLE beacon which advertises itself with the link to the website. This can be done with the Eddystone beacon format. |
| **Task 2** Implement the receiver of advertising frames broadcasted by the beacon device capable of displaying information on the LCD screen. | **Task 2** Implement the receiver of advertising frames broadcasted by the beacon device capable of displaying information on the LCD screen. | ||
| ==== Start ==== | ==== Start ==== | ||
| - | We need to implement both software to be able to observe the results. **Task 1** | + | We need to implement both parts of the software to be able to observe the results |
| ==== Steps ==== | ==== Steps ==== | ||
| Line 32: | Line 32: | ||
| Let's begin with including Arduino and BLE libraries. | Let's begin with including Arduino and BLE libraries. | ||
| <code c> | <code c> | ||
| - | # | + | # |
| #include " | #include " | ||
| #include " | #include " | ||
| Line 67: | Line 67: | ||
| | 0x02 | 0x0A | Tx Power Level | 0x09 | | | 0x02 | 0x0A | Tx Power Level | 0x09 | | ||
| - | Except for the text information as the device name, it is possible to send other data such as the web address which directs us to additional information. There are some formats defined for use in beacon devices. One of them is Eddystone invented by Google. It is used in the advertisement frames for simplification of the URL encoding. It requires the presence of the field (code 0x03) which shows the list of 16-bit UUIDs with 0xAAFE value, and the service data field (code 0x16) compatible with Eddystone format. These additional fields are shown in the table below. | + | Except for the text information as the device name, it is possible to send other data such as the web address which directs us to additional information. There are some formats defined for use in beacon devices. One of them is Eddystone invented by Google. It is used in the advertisement frames for simplification of the URL encoding. It requires the presence of the field "List of 16-bit UUIDs" |
| - | ^ Field length | + | ^ Field length |
| | 3 | 0x03 | Complete list of 16-bit service UUIDs | 0xAAFE | | 3 | 0x03 | Complete list of 16-bit service UUIDs | 0xAAFE | ||
| | 14 | 0x16 | Service data | Eddystone format | | 14 | 0x16 | Service data | Eddystone format | ||
| - | The Eddystone field starts with service UUID (0xAAFE), next specifies the content type (0x10 for URL), then the transmitting power in [dBm], and then the compressed URL. To compress URLs some default prefixes and suffixes were defined as non-ASCII characters. They are presented in the tables below. | + | The Eddystone field starts with service UUID (0xAAFE), next specifies the content type (0x10 for URL), then the transmitting power in [dBm], and then the compressed URL. |
| + | < | ||
| + | The UUID of Eddystone appears twice. Once as the element of the list of available services, the second time as the identifier of the service field. | ||
| + | </ | ||
| + | To compress URLs some default prefixes and suffixes were defined as non-ASCII characters. They are presented in the tables below. | ||
| ^ Decimal ^ Hex ^ Prefix ^ | ^ Decimal ^ Hex ^ Prefix ^ | ||
| Line 190: | Line 194: | ||
| pBLEScan-> | pBLEScan-> | ||
| } | } | ||
| - | < | + | </code> |
| + | In the loop function, we restart scanning every 5 seconds with 1 second delay. | ||
| + | < | ||
| + | The start function of the BLEScan class is blocking, so it stops program execution for the time of scanning. | ||
| + | </ | ||
| + | <code c> | ||
| + | void loop() { | ||
| + | delay(1000); | ||
| + | // Repeat scanning | ||
| + | pBLEScan-> | ||
| + | } | ||
| + | </ | ||
| + | === Step 4 === | ||
| The callback function checks if the device which sent the advertising frame implements the Eddystone service. This is how we filter out all other BLE devices available in the range. | The callback function checks if the device which sent the advertising frame implements the Eddystone service. This is how we filter out all other BLE devices available in the range. | ||
| < | < | ||
| Line 247: | Line 263: | ||
| }; // MyAdvertisedDeviceCallbacks | }; // MyAdvertisedDeviceCallbacks | ||
| </ | </ | ||
| - | + | Additional filtering of remote devices can be done with their names. We can add in the " | |
| - | In the loop function, we restart scanning every 5 seconds | + | |
| - | < | + | |
| - | The start function of the BLEScan class is blocking, so it stops program execution for the time of scanning. | + | |
| - | </ | + | |
| <code c> | <code c> | ||
| - | void loop() { | + | String name; |
| - | delay(1000); | + | name = advertisedDevice.getName().c_str(); |
| - | // Repeat scanning | + | if (name.equals(" |
| - | pBLEScan-> | + | |
| - | } | + | |
| + | } | ||
| </ | </ | ||
| - | === Step 4 === | + | |
| + | === Step 5 === | ||
| Let's return to the beacon device. The advertisement frame is quite short so normally additional information is sent upon Scan Request with Scan Response frame. It can contain the device name which can differ from the name we specified in step 1 (in the case of normal operation we can read it as the value of the Generic Access Service). To specify different names in advertising frame and service characteristics we can use the setScanResponseData() function from BLEAdvertising class. | Let's return to the beacon device. The advertisement frame is quite short so normally additional information is sent upon Scan Request with Scan Response frame. It can contain the device name which can differ from the name we specified in step 1 (in the case of normal operation we can read it as the value of the Generic Access Service). To specify different names in advertising frame and service characteristics we can use the setScanResponseData() function from BLEAdvertising class. | ||
| <code c> | <code c> | ||
| Line 267: | Line 281: | ||
| ==== Result validation ==== | ==== Result validation ==== | ||
| - | You should be able to observe | + | After the implementation of steps 1-4, you should be able to see the name of the beacon device |
| ==== Further work ==== | ==== Further work ==== | ||
| - | You can try the example software for the beacon device which is available in the examples at the path: | + | You can try to implement the beacon device compatible with iBeacon. The description can be found on the website ((https:// |
| - | < | + | |
| - | C: | + | |
| - | </ | + | |
| - | It is more complex but enables automatic determination of packet length depending on the URL provided. | + | |
| - | \\ | + | |
| - | You can also try to implement the beacon device compatible with iBeacon. The description can be found on the website ((https:// | + | |
| ===== FAQ ===== | ===== FAQ ===== | ||
