How to increase ATT MTU to more than 65 Bytes in peripheral NUS sample app?

[Lex_Ek]

Hi,

I am using the Nordic UART Service (NUS) peripheral and central on two nRF52840 DKs and I am developing with nRF Connect SDK v3.0.0.

I can't manage to increase the ATT MTU size to larger than 65 Bytes. I don't even know where this 65 Bytes value is coming from. I also don't know if I should change something in the central or the peripheral's code base. Anyway, I have an output from Wireshark:

Unfortunately, I have failed to find any useful information/instructions about this. Of course, I have even consulted with an AI chatbot, but none of its suggestions seem to work.

(I am new to Zephyr and nRF Connect SDK. Last time I programmed BLE was years ago, with nRF5 SDK and SES, but I remember increasing the MTU was sooo easy in comparison!)

Thanks for your help in advance!

[Hieu]

Hi Lex_Ek,

In the nRF Connect SDK, these configurations are done via Kconfig. I recommend going over our nRF Connect SDK Fundamentals course to familiarize yourself with the concepts and environments of the SDK.

The value of 65 is the default when CONFIG_BT_SMP is enabled, which is set by default in the Peripheral UART sample, albeit in a not very beginner friendly way. You can just accept this fact as is and go into it later, but here are the relevant piece of code:
https://github.com/nrfconnect/sdk-zephyr/blob/v4.0.99-ncs1/subsys/bluetooth/host/Kconfig.l2cap#L28-L45
https://github.com/nrfconnect/sdk-nrf/blob/v3.0.0/samples/bluetooth/peripheral_uart/Kconfig#L23-L28

To get maximum throughput between two nRF devices, I recommend you refer to the configurations in the Throughput samples:
https://github.com/nrfconnect/sdk-nrf/blob/v3.0.0/samples/bluetooth/throughput/prj.conf#L32-L44

Hieu

[Lex_Ek]

Hi,

Thank you for the links, I will go through the course!

However, I have some follow up comments and questions:

1) My aim is not to get the maximum throughput. Rather my aim is to send one packet at a time, of at least 128 Bytes, as reliably as possible at certain connection intervals (e.g. at 15ms, 10 ms, 7.5 ms). For this I have modified the NUS sample by setting up a message sending thread and a timer that wakes the thread up at a certain pre-set interval. I also set the conn interval to a lower value than the message sending, thus ensuring that one packet is sent at each conn interval.

2) In order to achieve my goal, do you suggest that I disable CONFIG_BT_SMP? Or what is the best thing to do?

[Hieu]

Hi Lex_Ek,

CONFIG_BT_SMP enables the Security Manager Protocol, which enable BLE Security feature, the most relevant of which in this case is pairing. You are free to enable or disable it as you need.

I merely brought it up because it explains why ATT MTU is negotiated to 65 bytes, instead of the minimum or the maximum value. Ref the piece of codes I linked.

For your purpose, you will want to reference these Kconfig from the Throughput sample then:

https://github.com/nrfconnect/sdk-nrf/blob/v3.0.0/samples/bluetooth/throughput/prj.conf#L32-L39

That will give you a maximum possible ATT MTU of 498, which can fit your 128-byte payload in one ATT operation.

If you want to minimize RAM usage, you can reduce the MTU and ACL buffer configs by ~350, or even more.

Optionally, you also want to maximize the link layer data length so that the whole ATT operation isn't segmented into multiple air packet. Everything should still work after this.

https://github.com/nrfconnect/sdk-nrf/blob/v3.0.0/samples/bluetooth/throughput/prj.conf#L41