Differences

This shows you the differences between two versions of the page.

--- en:edu:zmitac:s2:aih:lab:nrf52zephyrblebeacon [2023/12/09 13:59] – ktokarz
+++ en:edu:zmitac:s2:aih:lab:nrf52zephyrblebeacon [2023/12/09 18:42] (current) – ktokarz
@@ Line 3: / Line 3: @@
 This example advertises the device as the "Test beacon" with details provided in Eddystone (([[https://en.wikipedia.org/wiki/Eddystone_(Google)]])) format.
-After importing it to the Visual Studio Code we should make some configuration: remove the unwanted build target from platformio.ini, and if we want to receive messages via serial port enable it within prj.conf.
+After importing it to the Visual Studio Code we should make some configuration: remove the unwanted build target from platformio.ini, and if we want to receive messages via serial port enable it within prj.conf. Notice that to use BLE it is enabled by default in the example's prj.conf file.
+<code>
+CONFIG_BT=y
+CONFIG_BT_DEBUG_LOG=y
+CONFIG_BT_DEVICE_NAME="Test beacon"
+</code>
 This example starts the Bluetooth interface with the function bt_enable() that passes the pointer to the bt_ready() which is the callback function to notify that initialization has finished.
 <code>
@@ Line 9: / Line 14: @@
 </code>
-Inside this bt_ready() function, we call bt_le_adv_start() function to start advertising.
+Inside this bt_ready() function, we call bt_le_adv_start() function to start our device to function as the server (broadcaster) and begin advertising.
 <code>
 bt_le_adv_start(BT_LE_ADV_NCONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
 </code>
-The beacon example is very simple because the beacon device is intended to advertise only so, there is no further functionality implemented. This example shows the so-called Eddystone format (([[https://en.wikipedia.org/wiki/Eddystone_(Google)]])) of Bluetooth Beacons that send simple information to nearby devices. To reduce the number of bytes sent in the advertisement frame the Eddystone format defines the list of prefixes and suffixes that can be used in the URL ((https://github.com/google/eddystone/tree/master/eddystone-url)).
-For example, web prefixes can be encoded as in the table.
-^ Decimal  ^ Hex   | Prefix        |
+The argument "BT_LE_ADV_NCONN" specifies the advertising mode without the possibility of accepting connections from a client (observer).
-| 0        | 0x00  | %%http://www.%%   |
-| 1        | 0x01  | %%https://www.%%  |
+The "ad" structure holds the content of the advertising frame data.
-| 2        | 0x02  | %%http://%%   |
+<code>
-| 3        | 0x03  | %%https://%%  |
+static const struct bt_data ad[] = {
+	BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR),
+	BT_DATA_BYTES(BT_DATA_UUID16_ALL, 0xaa, 0xfe),
+	BT_DATA_BYTES(BT_DATA_SVC_DATA16,
+xaa, 0xfe, /* Eddystone UUID */
+x10, /* Eddystone-URL frame type */
+x00, /* Calibrated Tx power at 0m */
+x00, /* URL Scheme Prefix http://www. */
+		      'z', 'e', 'p', 'h', 'y', 'r',
+		      'p', 'r', 'o', 'j', 'e', 'c', 't',
+x08) /* .org */
+};
+</code>
+It contains three elements of specific types. The complete list of types with their identifiers you can find in the official Bluetooth SiG website ((https://bitbucket.org/bluetooth-SIG/public/src/main/assigned_numbers/core/ad_types.yaml)).
+<table bletypes>
+<caption> List of elements of the advertising frame data</caption>
+^ Type ID ^ Type name (as in BLE specification) ^ Content ^
+| 0x01 | Flags | specifies if BR/EDR is supported |
+| 0x03 | Complete List of 16-bit Service Class UUIDs | Eddystone UUID |
+| 0x16 | Service Data - 16-bit UUID | UUID and content of Eddystone data |
+</table>
+The "sd" argument is the structure that holds scan response data. This can be read by the observer with a scan request. It has the type of the name of the device and contains the text "Test beacon".
+<table blesdtypes>
+<caption> List of elements of the advertising frame scan response</caption>
+^ Type ID ^ Type name (as in BLE specification) ^ Content ^
+| 0x09 | Complete Local Name | name of the device |
+</table>
+You can observe the details in the nRF Connect application on your mobile phone.
+The beacon example is very simple because the beacon device is intended to advertise only, so there is no further functionality implemented. This example shows the so-called Eddystone format (([[https://en.wikipedia.org/wiki/Eddystone_(Google)]])) of Bluetooth Beacons that send simple information to nearby devices. To reduce the number of bytes sent in the advertisement frame the Eddystone format defines the list of prefixes and suffixes that can be used in the URL encoded as values of non-printable characters((https://github.com/google/eddystone/tree/master/eddystone-url)).
+For example, web prefixes can be encoded as in the table {{ref>eddyprefix}}.
+<table eddyprefix>
+<caption>Eddystone web prefixes</caption>
+^ Decimal  ^ Hex   ^ Prefix        ^
+| 0 | 0x00  |%%http://www.%%|
+| 1 | 0x01  |%%https://www.%%|
+| 2 | 0x02  |%%http://%%   |
+| 3 | 0x03  |%%https://%%  |
+</table>
+Web suffixes defined in Eddystone format are listed in the table {{ref>eddysuffix}}.
+<table eddysuffix>
+<caption>Eddystone web suffixes</caption>
+^ Decimal  ^ Hex   ^ Suffix  ^
+| 0        | 0x00  | .com/   |
+| 1        | 0x01  | .org/   |
+| 2        | 0x02  | .edu/   |
+| 3        | 0x03  | .net/   |
+| 4        | 0x04  | .info/  |
+| 5        | 0x05  | .biz/   |
+| 6        | 0x06  | .gov/   |
+| 7        | 0x07  | .com    |
+| 8        | 0x08  | .org    |
+| 9        | 0x09  | .edu    |
+| 10       | 0x0a  | .net    |
+| 11       | 0x0b  | .info   |
+| 12       | 0x0c  | .biz    |
+| 13       | 0x0d  | .gov    |
+</table>
+===== Tasks to do during the laboratory =====
+  - Import the Zephyr BLE Beacon example, compile it, and run.
+  - Use the nRF Connect application (For Android mobile) and find the "Test beacon" device.
+  - Modify the software obtaining different prefixes and suffixes for the beacon.
+  - Modify the name of the device with "Polsl Beacon", and the advertised web address with %%"https://www.polsl.pl"%%