This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

is DLE enabled by default in SoftDevice s140 ?

Hello!

I went through the example project "Experimental: ATT_MTU Throughput Example" provided in SDK v15.2.0 and found that there is a configuration bit in BLE_COMMON_OPTS that allows to enable / disable the Data Length Extension (DLE) for BLE 4.2 and higher.

The bit, called "conn_evt_len_ext_enabled" is part of the structure defined with type "ble_common_opt_t"

In the example, this bit can be modified in function conn_evt_len_ext_set() (in file main.c)

My questions are:

1. is this bit enabled by default in the SoftDevice s140 of SDK v15.0.0 and v15.2.0 or must it be enabled programmatically?

(i.e. is DLE enabled and available, so that changes in NRF_SDH_BLE_GAP_DATA_LENGTH can become effective?)

2. I have written a simple function to check the status of this bit:

bool conn_evt_len_ext_get(void)
{
    ret_code_t err_code;
    ble_opt_t  opt2;

// read back BLE option settings:
    memset(&opt2, 0x00, sizeof(opt2));
    err_code = sd_ble_opt_get(BLE_COMMON_OPT_CONN_EVT_EXT, &opt2);
    APP_ERROR_CHECK(err_code);

    if(opt2.common_opt.conn_evt_ext.enable != 0)
    {
      return true;
    }
    else
    {
      return false;
    }
} 

When calling this function at the end of all initializations, I get a runtime error:

 <error> app: ERROR 6 [NRF_ERROR_NOT_SUPPORTED]

What could be the reason of this error?

(NOTE that my application is a BLE peripheral and the mentioned code in the SDK is a "Central & Peripheral" example)

Thanks for any suggestions.

Parents
  • Hi Ricardo,

    I will copy the declaration of ble_common_opt_conn_evt_ext_t from ble.h in lines 270 - 284:

    /**
     * @brief Configuration of extended BLE connection events.
     *
     * When enabled the SoftDevice will dynamically extend the connection event when possible.
     *
     * The connection event length is controlled by the connection configuration as set by @ref ble_gap_conn_cfg_t::event_length.
     * The connection event can be extended if there is time to send another packet pair before the start of the next connection interval,
     * and if there are no conflicts with other BLE roles requesting radio time.
     *
     * @note @ref sd_ble_opt_get is not supported for this option.
     */
    typedef struct
    {
       uint8_t enable : 1; /**< Enable extended BLE connection events, disabled by default. */
    } ble_common_opt_conn_evt_ext_t; 

    As you can see here sd_ble_opt_get() is not supported for this option, and the extended BLE connection events are disabled by default.

    Best Regards,

    Marjeris

  • Hi Marjeris,

    thank you for your reply, but I'm not shure if I understood it correctly. 

    I would like to increase the on-air packet data length from the standard 27 bytes to 75 bytes. 

    Does this mean that I can just modify NRF_SDH_BLE_GAP_DATA_LENGTH in sdk_config.h and the SoftDevice will automatically try to negotiate and use this increased packet length without needing further changes? 

    Or does the user application code also have to set the enable bit (in the structure of type ble_common_opt_conn_evt_ext_t indicated in your post), since by default it is disabled? What library function should be used to set this bit? Is it the function sd_ble_opt_set() ?

    I understand that if this bit is set, I can no longer use the function sd_ble_opt_get().

    Thank you. Best regards.

    Ricardo

Reply
  • Hi Marjeris,

    thank you for your reply, but I'm not shure if I understood it correctly. 

    I would like to increase the on-air packet data length from the standard 27 bytes to 75 bytes. 

    Does this mean that I can just modify NRF_SDH_BLE_GAP_DATA_LENGTH in sdk_config.h and the SoftDevice will automatically try to negotiate and use this increased packet length without needing further changes? 

    Or does the user application code also have to set the enable bit (in the structure of type ble_common_opt_conn_evt_ext_t indicated in your post), since by default it is disabled? What library function should be used to set this bit? Is it the function sd_ble_opt_set() ?

    I understand that if this bit is set, I can no longer use the function sd_ble_opt_get().

    Thank you. Best regards.

    Ricardo

Children
  • Hi,

    there is a configuration bit in BLE_COMMON_OPTS that allows to enable / disable the Data Length Extension (DLE)

    Yes, I think maybe this was the misunderstanding. The ble_commont_opt_conn_evt_ext_t is a struct to configure extended BLE connection events. If you want to increase your packet data length it is not necessary to enable Connection Event Length Extension.

    To increase the packet data length I think you can either modify the parameter NRF_SDH_GAP_DATA_LENGTH in sdk_config.h or call the softdevice function sd_ble_gap_data_length_update().

    You can read more about how different parameters influence the throughput in this blog post.

    Best Regards,

    Marjeris

     

  • Hi Marjeris,

    thank you for your clarification. I tried it and can confirm all the following:

    • In order to increase the on-air packet data length it is not necessary to enable the Connection Event Length Extension or to change any other parameter
    • it suffices to do one of the two following things:
    • the change of packet data length takes effect immediately, provided that the peer supports the DLE feature (i.e. iPhone7 or newer, newer computers with BLE 4.2 or higher). Otherwise the packet data length will remain at 27.

    However, I noticed a problem with your actual version of nRF Sniffer (v2.0.0.2.beta):

    After changing the packet data length on an existing connection (sniffed correctly so far), the nRF Sniffer looses track of the encryption as soon as a packet is sent with a data length larger than the default 27 bytes. Starting from this moment, all subsequent packets are flagged with the following error message:

    "Encrypted packet decrypted incorrectly (bad MIC)"

    even if their packet data length is smaller than 27 bytes.

    I will post a separate ticket on this issue: see here.

    Thank you!

    Best regards.

Related