NRF52/BLE4.2 data data throughout

RE: NRF52/BLE4.2 data data throughout

Sigurd — Wed, 14 Jun 2017 07:49:32 GMT

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);

RE: NRF52/BLE4.2 data data throughout

simon — Tue, 13 Jun 2017 15:07:43 GMT

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?

RE: NRF52/BLE4.2 data data throughout

endnode — Tue, 13 Jun 2017 09:09:56 GMT

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).

RE: NRF52/BLE4.2 data data throughout

Sigurd — Tue, 13 Jun 2017 09:09:17 GMT

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