Changing MTU size using data length extension

RE: Changing MTU size using data length extension

Marjeris Romero — Thu, 06 May 2021 07:20:13 GMT

Hi Shemin,

Please open a new ticket in Devzone if you need help with this. This thread is 2 years old. Click on the 'Support+' ticket on the right side of the search bar and then click to open a new public Q&A ticket.

Best regards,

Marjeris

RE: Changing MTU size using data length extension

Shemin Nizar — Thu, 06 May 2021 04:36:01 GMT

Hi , I have also tried to user android device as a peripheral to communicate with remote nrf52 device, but due to rx and tx octet mismatching of data symmetric issue , after mtu exchange communication not able to continue like for notification enable , sending image information , but using nrf connect app it s working .

Will you please able to help fix this issue

Regards,

Shemin

RE: Changing MTU size using data length extension

Marjeris Romero — Wed, 28 Aug 2019 11:18:20 GMT

Hi,

Happy to help :) first part of the log output says the packet data length is being updated to 27 (both for RX and TX). The ATT packet will then be sent over several on-air packets, see Bjørn's answer in this ticket.

Best regards,

Marjeris

RE: Changing MTU size using data length extension

Kasper Leonhardt — Tue, 27 Aug 2019 07:05:58 GMT

Hi,

I was referring to the third party app "BLE scanner" from BluePixel. I have tried "nFR Connect" It seems to better handle the long writes. And my peripheral device application works fine.

[00:00:13.122,000] <info> app: Peripheral connected
[00:00:13.122,000] <info> app: Sending PHY Update.
[00:00:13.223,000] <warning> app: Backends flushed
[00:00:13.234,000] <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x1.
[00:00:13.234,000] <debug> nrf_ble_gatt: max_rx_octets: 27
[00:00:13.234,000] <debug> nrf_ble_gatt: max_tx_octets: 27
[00:00:13.234,000] <debug> nrf_ble_gatt: max_rx_time: 328
[00:00:13.234,000] <debug> nrf_ble_gatt: max_tx_time: 328
[00:00:13.234,000] <info> app: Data length updated to 27 bytes.

[00:00:13.483,000] <debug> nrf_ble_gatt: ATT MTU updated to 64 bytes on connection 0x1 (response).
[00:00:13.483,000] <info> app: ATT MTU exchange completed. MTU set to 64 bytes.
[00:00:13.634,000] <info> app: PHY update rejected. PHY set to 1 Mbps.

[00:01:37.643,000] <info> app: on_write: patient handle: 37 Len: 30

I do not understand the first part of the log with the data length and max_?_octets. But "ATT MTU exchange completed. MTU set to 64 bytes." and "app: on_write: patient handle: 37 Len: 30" says it all. :-)

Thanks for your guidance.

Kasper

RE: Changing MTU size using data length extension

Marjeris Romero — Mon, 26 Aug 2019 13:18:13 GMT

Hi,

With BLE scanner do you mean "nRF Connect app"? You should be using nRF Connect app for Android.

And we recommend using nRF Sniffer v2.

Best regards,

Marjeris

RE: Changing MTU size using data length extension

Kasper Leonhardt — Thu, 22 Aug 2019 09:13:07 GMT

Hi Marjeris

Thanks for your reply.

I have tried with the following devices.

Samsung S10+ (Android 9) (Supports 2Mbps, and apparently only RX/TX:>67/27)
Alcatel 8082 1T EEA (Android 8.1) (Will soon be tested)
Sony Z5 Compact (LinageOS, Android 7.1.2) (Supports only 1Mbps, and apparently only RX/TX:>67/27, reduced later to 27/27 by phone) (Used for the trace in the original post)
Lenovo Tablet TB-8304F1 (Android 7.0) (Supports only 1Mbps, and apparently only RX/TX:27/27)

The Samsung phone seems to do the same as the Sony phone, except that the data length is NOT reduced to 27 even that it is not symmetric:

[00:36:18.813,000] <info> app: Peripheral connected
[00:36:18.813,000] <info> app: Sending PHY Update.
[00:36:18.901,000] <debug> nrf_ble_gatt: ATT MTU updated to 64 bytes on connection 0x1 (response).
[00:36:18.901,000] <info> app: ATT MTU exchange completed. MTU set to 64 bytes.
[00:36:18.904,000] <warning> app: Backends flushed
[00:36:19.291,000] <debug> nrf_ble_gatt: Data length updated to 67 on connection 0x1.
[00:36:19.291,000] <debug> nrf_ble_gatt: max_rx_octets: 27
[00:36:19.291,000] <debug> nrf_ble_gatt: max_tx_octets: 67
[00:36:19.291,000] <debug> nrf_ble_gatt: max_rx_time: 328
[00:36:19.291,000] <debug> nrf_ble_gatt: max_tx_time: 2120
[00:36:19.291,000] <info> app: Data length updated to 67 bytes.
[00:36:19.760,000] <info> app: PHY update accepted. PHY set to 2 Mbps.
[00:36:43.604,000] <debug> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
[00:36:45.588,000] <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 1, procedure: Bonding
[00:36:45.588,000] <info> app: Link status. Role: 1. conn_handle: 1, Procedure: 1
[00:36:45.588,000] <info> app: BLE_GAP_EVT_AUTH_STATUS: status=0x0 bond=0x1 lv4: 0 kdist_own:0x3 kdist_peer:0x3
[00:36:46.088,000] <info> app: on_write: handle: 22 Len: 4
[00:37:02.077,000] <info> app: Peripheral disconnected. conn_handle: 0x1, reason: 0x13

Can you recommend any other app for browsing services and reading/writing characteristics. I cannot find any other than BLE Scanner. Are you aware of apps that can display the capabilities for DataLengtExtensien? Bluetooth version implementation?

I will try to set up the BLE Sniffer later. (Not a trivial task, last time I gave up. I miss the old BLE Sniffer three years which was much easier to setup)

BR
Kasper

RE: Changing MTU size using data length extension

Marjeris Romero — Wed, 21 Aug 2019 15:03:19 GMT

Hi Kasper,

Sorry for the late answer. The Softdevice only supports symmetric RX/TX data length settings, from the logs you can see RX setting was different from TX so that's why TX sets to 27. Can you try to setup the BLE sniffer to see what is happening between your device and your phone? What kind of phone are you using? Are you sure it supports higher data lengths? It needs to support DLE for both TX and RX.

[quote user=""]I have read some guides that tells that besides defining your needed data length, you also needs to enable data length extension. But how? Is this done automatically by the softdevice?[/quote]

This is done automatically by the GATT module when you define a higher data length.

Best regards,

Marjeris