Configuring the Link Layer for DLE with s132 v4.0.2?

[Elias]

With s132 v3, in addition to configuring the GATT to receive larger packets like so:

ble_enable_params.gatt_enable_params.att_mtu = 247;
err_code = softdevice_enable(&ble_enable_params);

you also had to configure the link layer:

ble_opts.gap_opt.ext_len.rxtx_max_pdu_payload_size = 251;
err_code = sd_ble_opt_set(BLE_GAP_OPT_EXT_LEN, &ble_opts);

I'm now migrating to v4.0.2 and according to the migration document, the first call has been replaced with one to sd_ble_cfg_set(), but the parameter used in the second one, BLE_GAP_OPT_EXT_LEN, is just removed. It presents sd_ble_gap_data_length_update() as a replacement, but it's used during a connection, not during configuration.

So, is link layer configuration now deferred so it can be modified link-by-link?

Also, if that's true, and sd_ble_gap_data_length_update() is to be called in response to BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST, how is the event actually triggered? It seems like it would be used as a replacement of BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST, but that is not made explicit.

[Petter Myhre]

Does the Data Length Update Procedure section in the migration document answer your question?

Edit 19.03.2017:

If you want to increase the ATT MTU you should add the following configuration:

#define CONN_CFG_TAG                    1
#define NRF_BLE_GATT_MAX_MTU_SIZE       247

memset(&ble_cfg, 0x00, sizeof(ble_cfg));
ble_cfg.conn_cfg.conn_cfg_tag                 = CONN_CFG_TAG;
ble_cfg.conn_cfg.params.gatt_conn_cfg.att_mtu = NRF_BLE_GATT_MAX_MTU_SIZE;
err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATT, &ble_cfg, ram_start);
APP_ERROR_CHECK(err_code);

And reference this tag when you advertise or connect:

sd_ble_gap_adv_start(&adv_params, CONN_CFG_TAG);

sd_ble_gap_connect(&p_gap_evt->params.adv_report.peer_addr,
                                  &m_scan_param,
                                  &m_conn_param,
                                  CONN_CFG_TAG);

And then call sd_ble_gattc_exchange_mtu_request() and/or react to the BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST event.

If you want to increase the LL data length call sd_ble_gap_data_length_update() or react to the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST event.

You should also modify the maximum connection event length, for example for a 400 ms connection interval:

// Configure the maximum event length.
memset(&ble_cfg, 0x00, sizeof(ble_cfg));
ble_cfg.conn_cfg.conn_cfg_tag                     = CONN_CFG_TAG;
ble_cfg.conn_cfg.params.gap_conn_cfg.event_length = 320;
ble_cfg.conn_cfg.params.gap_conn_cfg.conn_count   = BLE_GAP_CONN_COUNT_DEFAULT;
err_code = sd_ble_cfg_set(BLE_CONN_CFG_GAP, &ble_cfg, ram_start);
APP_ERROR_CHECK(err_code);

I also recommend studying the ble_app_att_mtu_throughput example.

Let me know if anything is unclear.

[Elias]

Not directly. Edited my question.

[xeem]

Is there any reason that the MTU is limited to 247? I would think you could increase this number by changing the starting RAM but it looks like the new API automatically allocates memory?

[Elias]

Turns out my issue was the maximum event length. Please report a note to change the description of NRF_ERROR_RESOURCES for sd_ble_gap_data_length_update(). No idea where/what "p_dl_limitation" is, and referencing the event length would be much more helpful.

[Andrzej Kuros]

What will happen if I do exchange mtu procedure but not execute sd_ble_gap_data_length_update(). Do I need to execute both procedures? If sd_ble_gap_data_length_update() procedure is not called but ATT_MTU is raised to say 247 bytes, will WriteCommand (3.4.5.3 od BT 4.2 core spec) be sliced somehow to fit smaller LL data size? What about limit of 6 transmissions per connection event?