Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Confused about how to set data length

During my development, I found NRF5 SDK only supports symmetric RX/TX data length settings.

Here is the on_data_length_update_request_evt in nrf_ble_gatt.c file.

static void on_data_length_update_request_evt(nrf_ble_gatt_t * p_gatt, ble_evt_t const * p_ble_evt)
{
ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
nrf_ble_gatt_link_t * p_link = &p_gatt->links[p_gap_evt->conn_handle];

// The SoftDevice only supports symmetric RX/TX data length settings.
uint8_t const data_length_requested =
p_gap_evt->params.data_length_update_request.peer_params.max_tx_octets;

NRF_LOG_DEBUG("Peer on connection 0x%x requested a data length of %u bytes.",
p_gap_evt->conn_handle, data_length_requested);

uint8_t const data_length_effective = MIN(p_link->data_length_desired, data_length_requested);
(void) data_length_update(p_gap_evt->conn_handle, data_length_effective);
}

It clearly indicates SDK only supports symmetric RX/TX data length settings.

When other Bluetooth devices send LL LENGTH RSQ, NRF will only take a minimum value to reply with the same RX TX.

This is also verified in wireshark.

But, I can still manually set an unsymmetric parameter and reply via sd_ble_gap_data_length_update.

case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
{
ble_gap_data_length_params_t params =
{
.max_rx_octets = 251,
.max_tx_octets = 132,
.max_rx_time_us = 2120,
.max_tx_time_us = 2120,
};
err_code = sd_ble_gap_data_length_update(conn_handle,&params,NULL);
APP_ERROR_CHECK(err_code);
}

It also can works and verified in wireshark.

So I'm wondering if it's a wrong behavior that I manually reply the unsymmetric parameters? 

Does it take effect inside the Bluetooth stack? Does the data transfer really follow this unsymmetric parameter?

 Any reply will be appreciated.

  • Hi Vidar,

    Thank you for your response—everything’s working great now! I’m actually using SDK 15.3, which doesn’t include the NRF_BLE_GATT_MTU_EXCHANGE_INITIATION_ENABLED macro. I checked SDK 17.1 to confirm its scope, then commented out that section in gatt.c to simulate the macro’s behavior. In main(), I set up a 500 ms timer so that, when acting as a peripheral, it triggers the MTU exchange 500 ms after BLE_GAP_EVT_CONNECTED. The code runs perfectly, and the phone no longer repeatedly requests an asymmetric LL LENGTH (I suspect the previous MTU exchange wasn’t actually effective).

    Thanks again for your guidance.

    Best regards,
    Harry

Related