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.

• Is it possible to send 1020 bytes payload data in a single connection interval? If yes, how?

[ovrebekk]

Hi Armand

The most efficient way to send a large payload over BLE is to split it manually into 244 byte blocks, since this is the maximum amount of user data you can have in one BLE packet. 

1020 bytes would have to be split into 5 packets in order to fit in 244 bytes or less (244 x 4 + 44). 

Depending on your configuration you should be able to send 5 packets or more in a single connection event, unless the connection interval is very small. 

If you look at the Bluetooth configuration in the throughput sample you can see how to configure the stack for optimal throughput:
https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/throughput/prj.conf#L31-L42

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