You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement proposal related to a problem? Please describe.
There are currently no in-tree examples of the Kconfig options and code flow required to setup a GATT connection to use a larger MTU than the default.
Given the multiple Kconfig namespaces that these options cross, a single reference example would be appreciated.
An example of the confusions and open questions from #25561. CONFIG_BT_ACL_RX_COUNT needs to be increased from its default value of 1. CONFIG_BT_CTLR_RX_BUFFERS, which sets the default value of CONFIG_BT_ACL_RX_COUNT should however not be incremented. Do CONFIG_BT_L2CAP_TX_MTU and CONFIG_BT_L2CAP_RX_MTU need to increased? One of these depends on CONFIG_BT_HCI_ACL_FLOW_CONTROL, which should not be enabled.
Describe the solution you'd like
A variant of the samples/bluetooth/central application that additionally increases the MTU of the connection to the largest values supported by the GATT client.
The proj.conf would contain the minimal configs necessary to achieve this.
The Nordic NCS repository has a GATT throughput example that does increase the MTU.
This example uses Nordics custom BT controller, which means the proj.conf is not valid for the combined controller/host builds that are the default for Zephyr. https://github.com/nrfconnect/sdk-nrf/tree/master/samples/bluetooth/throughput
The text was updated successfully, but these errors were encountered:
# Uncoded LE Data Packet Format:
#
# | Preamble | Access | PDU (2 to 257 bytes) | CRC |
# | | Address | LL Header | Link Layer PDU (0 to 251 bytes) | MIC | |
# | | | | L2CAP Header | L2CAP PDU (0-247 bytes) | Optional | |
# | | | | | ATT Header | ATT Payload | | |
# | | | | | OpCode | Handle | | | |
# | 1 byte | 4 bytes | 2 bytes | 4 bytes | 1 byte | 2 bytes | 0 - 244 bytes | 4 bytes | 3 bytes |
#
# L2CAP can be larger than 247 bytes, but will be split across multiple LL packets as a result.
# ATT payloads can be larger than 244 bytes, but will be split across multiple LL packets as a result.
#
#
# Kconfig Symbols:
# CONFIG_BT_CTLR_DATA_LENGTH_MAX : Maximum payload size of the Link Layer PDU
# CONFIG_BT_BUF_ACL_TX_SIZE : Maximum L2CAP PDU is limited to this value - 4
# CONFIG_BT_BUF_ACL_RX_SIZE : Maximum L2CAP PDU is limited to this value - 4
# CONFIG_BT_L2CAP_TX_MTU : Maximum L2CAP PDU size for transmission
In the meantime, here is documentation I made for others struggling with configuring this
Hi @JordanYates, do you think that the newly added sample is enough? We would like to get your feedback to know if we should improve it or if we could close this issue.
Is your enhancement proposal related to a problem? Please describe.
There are currently no in-tree examples of the Kconfig options and code flow required to setup a GATT connection to use a larger MTU than the default.
Given the multiple Kconfig namespaces that these options cross, a single reference example would be appreciated.
An example of the confusions and open questions from #25561.
CONFIG_BT_ACL_RX_COUNT
needs to be increased from its default value of 1.CONFIG_BT_CTLR_RX_BUFFERS
, which sets the default value ofCONFIG_BT_ACL_RX_COUNT
should however not be incremented. DoCONFIG_BT_L2CAP_TX_MTU
andCONFIG_BT_L2CAP_RX_MTU
need to increased? One of these depends onCONFIG_BT_HCI_ACL_FLOW_CONTROL
, which should not be enabled.Describe the solution you'd like
A variant of the
samples/bluetooth/central
application that additionally increases the MTU of the connection to the largest values supported by the GATT client.The proj.conf would contain the minimal configs necessary to achieve this.
Describe alternatives you've considered
Improved documentation under:
https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-dev.html
or
https://docs.zephyrproject.org/latest/reference/bluetooth/gatt.html
Would also be an alternative.
Additional context
The Nordic NCS repository has a GATT throughput example that does increase the MTU.
This example uses Nordics custom BT controller, which means the proj.conf is not valid for the combined controller/host builds that are the default for Zephyr.
https://github.com/nrfconnect/sdk-nrf/tree/master/samples/bluetooth/throughput
The text was updated successfully, but these errors were encountered: