Increasing MTU ATT to 1020 bytes generates a CMake error

[Ignacio]

Hi,

Using the central and peripheral uart samples I have found the following CMake error when trying to increase the MTU ATT to 1020 bytes.

The added lines to the prj.conf are:

CONFIG_BT_BUF_ACL_RX_SIZE=1024
CONFIG_BT_BUF_ACL_TX_SIZE=1024
CONFIG_BT_L2CAP_TX_MTU=1020
#CONFIG_BT_CTLR_DATA_LENGTH_MAX=1024

The CMake error as follows:

CMake Error at C:/v1.8.0/v1.8.0/zephyr/cmake/kconfig.cmake:270 (message):
  command failed with return code: 1

Any help?

Thanks

[ovrebekk]

Hi Armand.

If you scroll up in the build log you should see a text like this:

warning: user value 1024 on the int symbol BT_BUF_ACL_TX_SIZE (defined at C:\ncs\v1.8.0\zephyr\subsys\bluetooth\common\Kconfig:7, c:\ncs\v1.8.0\_cust\285777_peripheral_hr\build\subsys\bluetooth\common\Kconfig:7) ignored due to being outside the active range ([27, 251]) -- falling back on defaults

error: Aborting due to Kconfig warnings

Essentially you have exceeded the maximum value for this configuration parameter, and you need to adjust it accordingly. 

If you adjust CONFIG_BT_BUF_ACL_TX_SIZE parameter to 251 it should build. 

Best regards
Torbjørn

[Ignacio]

Thanks Torbjørn,

Just for me to fully understand and close the case. The article on the link below states the following:

www.novelbits.io/.../

There is no limit per the spec on how high the MTU value can be, but the specific stack in use may have its own limitations

Could you confirm that the 244 bytes payload per packet is a specific stack limitation?

[Turbo J]

It is a hardware specific limitation - at least that is what I read from the RADIO peripherial specification. A TX packet can only be up to 255 bytes in length - that register has only 8 bits.

I'm pretty sure you could configure the zephyr BT stack for supporting a RADIO with a larger possible TX packet size, but I don't see this possible with currently available NordiSemi chips that I'm aware of.

[Ignacio]

Thanks, Turbo and Torbjørn,

One final query. Is it possible to set to CONFIG_BT_L2CAP_TX_MTU=1020 and get the ble stack to split the messages? If yes, how?

Zephyr specified that CONFIG_BT_L2CAP_TX_MTU can be configured up to 2000.

docs.zephyrproject.org/.../CONFIG_BT_L2CAP_TX_MTU.html

 

[ovrebekk]

Hi Armand

Ignacio said:

One final query. Is it possible to set to CONFIG_BT_L2CAP_TX_MTU=1020 and get the ble stack to split the messages? If yes, how?

This should be possible, yes, but using L2CAP connection oriented channels is not a very common way of sending data over BLE. Then you bypass the entire ATT and GATT layer, which means you can't use normal BLE services. 

Are you sure this is what you want to do?

Could you give me some information about the application you are working on, and what kind of devices you want to connect? 

Do you have Nordic devices on both sides of the link, or do you want to connect to other devices like phones or PC's?

Best regards
Torbjørn

[Ignacio]

Nordic devices on each side. I think I will manually split the messages for now. I just wanted to understand why CONFIG_BT_L2CAP_TX_MTU  can be set up to 2000 on the zephyr specs. Any hint?

[ovrebekk]

Hi Armand

L2CAP packets are only limited by the 16-bit length field, which means they can be up to 65536 bytes long pr spec. 

Attributes are limited to 512 bytes pr spec, so when running normal communication through ATT there is little need for an MTU larger than 515 bytes (512 bytes for data and 3 bytes for the attribute header). 

If you bypass ATT and open an L2CAP Connected Oriented Channel you are not limited to 512 bytes, but the practical implication on data throughput will not be very large since the link layer still needs to fragment the packets into 251 byte payloads over the air. 

Best regards
Torbjørn