SiliconLabsSoftware · silabs-vm · Jul 13, 2026 · Jun 23, 2026 · Jun 23, 2026 · Jun 23, 2026
@@ -65,9 +65,18 @@ Maximum Transfer Unit (MTU) specifies the number of bytes that can be sent withi
 |1.0.x|23|
 |2.0.x|58|
 |2.1.x|126|
-|2.3.x or later|250|
+|2.3.x|250|
+|10.0.x or later|512 or higher|
 
-Note that the MTU size depends on both sides. For example, if the remote device supports a smaller MTU size, the smaller MTU size will be used. The higher the MTU size, the higher the throughput. Twice the MTU size doubles the throughput.
+Note that the MTU size depends on the capabilities of both devices. If the remote device supports a smaller MTU size, the smaller MTU size is used. In general, a larger MTU size allows higher throughput. For example, if the MTU size is doubled, throughput may be double. In the latest SDKs, the maximum ATT MTU is, in practice, limited only by the configured BGAPI payload size. 
+
+With a sufficiently large BGAPI payload size, the full characteristic value can be read or written in a single operation. The maximum characteristic value length that can be transferred in one operation is `SL_BGAPI_MAX_PAYLOAD_SIZE - 7` bytes. Therefore, to support the full 512‑byte length, SL_BGAPI_MAX_PAYLOAD_SIZE must be set to 520 bytes. 
+
+This value can be configured in the project `config/sl_bgapi_config.h` header file or through the user interface for SoC/NCP projects under **Software Components > Bluetooth > Bluetooth Host (Stack) > BGAPI Protocol**:
+
+![Unacknowledged data transfer](resources/bgapi_max_payload_size.png?darkModeUrl=resources/bgapi_max_payload_size.png)
+
+In case of NCP setups, it is recommended to match up larger BGAPI payloads with higher UART speeds to avoid any congestion/packet loss.
 
 ### Attribute Protocol (ATT) Operation
 
@@ -86,12 +95,12 @@ MTU size includes the GATT header, which has a variable length and means that th
 For acknowledged operations, the maximum throughput can be achieved with the following parameters:
 
 - Connection interval: **7.5 ms**
-- MTU size: **250 bytes**
+- MTU size: **513 bytes**
 - Attribute protocol operation used: **Read**
 
 This results in a maximum throughput of
 
-**1000 ms / (2 * 7.5 ms) * (250 - 1) bytes = 16,600 bytes/sec = 132,800 bps**
+**1000 ms / (2 * 7.5 ms) * (513 - 1) bytes = 34,133 bytes/sec = 273,066 bps**
 
 ## Throughput Calculation for Unacknowledged Data Transfer
 

@@ -11,6 +11,8 @@ Important points about Periodic Advertising are as follows:
 2. At least one advertisement packet needs to be sent to enable periodic advertising.
 3. It will use the same PHY as the auxiliary packet. Each periodic advertiser has the same parameters as connection. Additionally, the channel is also determined the same way as connection using the Channel Selection Algorithm #2.
 4. Because it is based on extended advertisements, it uses data channels as opposed to advertisements channels.
+5. Periodic advertising supports Adaptive Frequency Hopping (AFH). Similar to Bluetooth connections, the advertiser and synchronized scanners can dynamically avoid channels experiencing high interference, improving robustness and reliability in congested RF environments.
+
 
 ## Concept
 
@@ -22,7 +24,10 @@ Periodic advertising mode is indicated with the ADV_EXT_IND packets (legacy adve
 
 ![Timing of Periodic Advertising](resources/sld268-figure-1.jpg?darkModeUrl=resources/sld268-figure-1.jpg)
 
-If the data of the periodic advertisement does not fit into one packet, the AUX_SYNC_IND packet can be followed by AUX_CHAIN_IND packets. AUX_SYNC_IND along with AUX_CHAIN_IND make up a sequence of advertisements forming a periodic advertising train.
+If the data for a periodic advertisement does not fit in a single packet, the AUX_SYNC_IND packet can be followed by one or more AUX_CHAIN_IND packets. Together, AUX_SYNC_IND and AUX_CHAIN_IND form a sequence of advertisements known as a periodic advertising train.
+
+Periodic advertising also supports AFH. Because periodic advertisements use data channels and Channel Selection Algorithm #2, the channel map can be updated to exclude channels affected by interference. This allows the periodic advertising train to adapt to changing RF conditions, similar to Bluetooth LE connections.
+
 
 ![Periodic Advertising Train](resources/sld268-figure-4.png?darkModeUrl=resources/sld268-figure-4.png)
 

@@ -53,10 +53,10 @@ For more information about Bluetooth priority handling, see [Dynamic Multiprotoc
 
 The default priorities are chosen so that they can be used well in most use cases. However, default priorities may not always provide an optimal solution. For example, if in your application it is not important to connect quickly but it is very important to send data in every connection interval via an already established connection, you can lower the priority of the connection initiation process.
 
-The minimum and maximum priorities of each task type can be defined in a `sl_bt_bluetooth_ll_priorities` structure (find the definition of the structure in sl_bt_ll_config.h). To overwrite the default priorities, add a new line to `SL_BT_CONFIG_DEFAULT` in sl_bluetooth_config.h, as you see below:
+The minimum and maximum priorities of each task type can be defined in a `sl_btctrl_ll_priorities` structure (find the definition of the structure in sl_bt_ll_config.h). To overwrite the default priorities, add a new line to `SL_BT_CONFIG_DEFAULT` in sl_bluetooth_config.h, as you see below:
 
 ```c
-sl_bt_bluetooth_ll_priorities ll_priorities = { 191, 143,  //scan_min, scan_max
+sl_btctrl_ll_priorities ll_priorities = { 191, 143,  //scan_min, scan_max
                                              175, 127,  //adv_min,  adv_max
                                              135,   0,  //conn_min, conn_max
                                              55,  15,   //init_min, init_max

@@ -223,17 +223,17 @@ When the Bluetooth stack is used with other protocols in a multiprotocol environ
 The application needs to allocate the configuration struct and provide it for the Bluetooth stack:
 
 ```C
-sl_bt_bluetooth_ll_priorities  custom_priorities;
+sl_btctrl_ll_priorities  custom_priorities;
 static const sl_bt_configuration_t config = {
   //
   .bluetooth.linklayer_priorities = &custom_priorities,
   //
 };
 ```
 
-The `sl_bt_bluetooth_ll_priorities` struct must be initialized to default state by the `SL_BT_BLUETOOTH_PRIORITIES_DEFAULT` constant.
+The `sl_btctrl_ll_priorities` struct must be initialized to default state by the `SL_BT_BLUETOOTH_PRIORITIES_DEFAULT` constant.
 
-The `sl_bt_bluetooth_ll_priorities` struct contains following fields:
+The `sl_btctrl_ll_priorities` struct contains following fields:
 
 - `scan_min, scan_max, scan step` - The priority range for scan operation.
 

@@ -450,3 +450,13 @@ display_image 2 0 0
 Since the tag `8C:F6:81:B8:83:18` was unassociated from the network instead of factory reset, all the images stored to it were preserved, and therefore the tag can display the images after associating to a network.
 
 ![Since the tag 8C:F6:81:B8:83:18 was unassociated from the network instead of factory reset, all the images stored to it were preserved, and therefore the tag can display the images after associating to a network.](resources/sld679-image40.png)
+
+## ESL image throughput stress test
+
+The `image_throughput` command starts or stops an ESL image transfer stress test across synchronized ESL Tags. During the test, the Access Point repeatedly transfers images to eligible synchronized Tags to validate throughput, stability, and PAwR-based image distribution performance under load.
+
+The test supports limiting the number of participating Tags (`--max_count`) and restricting enrollment to Tags within a maximum ESL group ID (`--max_group`). While the test runs, the AP temporarily switches to manual mode and restores the previous operating mode automatically when the test finishes or is stopped. The test requires PAwR to be active, synchronized ESLs that support image transfer, and demo mode to be disabled.
+
+For full command usage, options, notes, and examples, see:
+
+`bt_host_esl_ap/esl_ap/readme/readme.md`