NRF52/BLE4.2 data data throughout

[simon]

Hi,

When i used nrf51822, i remember the s110 define max transmit buffer as 23 Bytes, but now, i am using nrf52832, the max transimit buffer is defined as 158 bytes. Does this is the general standard define in offical BLE 4.2? if so, is it means if i use 20ms for an interval, then, with nrf51822, the data throughout is about 23/20=1kbyte/s . and, with nrf52832, the data throughtout rate can achieve about 158/20=8kbyte/s. Am i right on this?

any one can help on this, it would be very grateful, thanks.

Regards Simon

[Sigurd]

Hi,

With BLE 4.1 the ATT MTU is 23 bytes, but with BLE 4.2 it can be increased up to 247 bytes. The throughput you can achieve also depends on the connection interval, how many packets you can send each connection event, and if you have enabled DLE (Data length extension) and Connection event length extension.

If both sides of the links supports all these settings, you can achieve ~770 kbps with BLE 4.2.

See these links for more information:

BLE data throughput

Throughput and long range demo

[endnode]

Not really, BT SIG leaves "default" ATT_MTU size unchanged on 23 bytes. Devices can exchange maximum MTU size capabilities once during the link and since then maximum size implicitly moves the the lower of two max values exchanged. This is managed by S132/140 Soft Devices on nRF52 chip where larger ATT_MTU sizes are supported (it seems never coming to nRF51 with Nordic Soft Devices due to RAM constrains).

Throughput is directly influenced by ATT_MTU size (if you run on top of (G)ATT layer of course;), you can see some example computation in the respective section of Nordic BT 4.2/5.0 throughput blog post. As you can see resulting throughput is also influenced by LL packet size aka PDU because higher-layer ATT_MTU must be split among several packets (and maximum sizes influence how much overhead you need to have).

[simon]

Hi Sigurd,

Thank you. I am new with nrf52832, so, I am confusing with DLE you mean. how can I enable the DLE? I am using the example code ".\ble_peripheral\ble_app_uart" And, I found in the example code, gatt_init() function call nrf_ble_gatt_att_mtu_periph_set(&m_gatt, 64); that means it set the MTU with value 64. but, the function ble_ecg_string_send(), it used if (length > BLE_NUS_MAX_DATA_LEN), but BLE_NUS_MAX_DATA_LEN was set (158-3). Do these have potential risk?

[Sigurd]

Actually the ble_app_uart in SDK 13 will by default try to enable DLE and increase the ATT_MTU. By default, it will try to set the ATT_MTU to 64 and set the DLE to NRF_BLE_GATT_MAX_MTU_SIZE + LL_HEADER_LEN. But you need to check the log to see if it was successfully increased (i.e. if the other device accepted the increase or not, by default the link starts with ATT_MTU 23 and no DLE, but it’s then negotiated higher). If you set the NRF_LOG_DEFAULT_LEVEL to DEBUG (#define NRF_LOG_DEFAULT_LEVEL 4 in sdk_config.h), you should be able to see the parameters that is negotiated between the central and peripheral. (Also remember to set #define NRF_LOG_BACKEND_SERIAL_USES_UART 1, if you are using UART as backend for NRF_LOG).

If DLE is not support on the other device, you will see the following values in the log:

nrf_ble_gatt:DEBUG:max_rx_octets: 27
nrf_ble_gatt:DEBUG:max_tx_octets: 27

For the ATT_MTU you will see something like this when it's updated:

nrf_ble_gatt:DEBUG:Updating ATT MTU to 64 bytes (desired: 64) on connection 0x0.
nrf_ble_gatt:DEBUG:ATT MTU updated to 64 bytes on connection 0x0 (response).
APP:INFO:Data len is set to 0x3D(61)

Depending on what settings the devices negotiate, the m_ble_nus_max_data_len will be updated in the gatt_evt_handler() function. When ble_nus_string_send() is used in uart_event_handle() there is a check so that it will not send anything longer than m_ble_nus_max_data_len:

if ((data_array[index - 1] == '\n') || (index >= (m_ble_nus_max_data_len)))
            {
                NRF_LOG_DEBUG("Ready to send data over BLE NUS\r\n");
                NRF_LOG_HEXDUMP_DEBUG(data_array, index);

                do
                {
                    err_code = ble_nus_string_send(&m_nus, data_array, index);