CC2640R2F: MTU Exchange is not happening.

Hi Muthu,

Thank you for evaluating the CC2640R2F and posting your question to the E2E Forum!  All of TI's BLE E2E Forum experts are taking a well-deserved time off on Monday, May 20th and will be returning to answer forum posts on Tuesday, May 21st in the order and priority in which they were received.  Until then, here are some resources you can further consider which may resolve your issue independently:

• Searching for relevant issues on the E2E forum
• Finding topic descriptions in the BLE5-Stack User's Guide
• Reading the SimpleLink SLA which covers similar behavior

If you find the solution to your problem then please respond to this E2E post!  Otherwise, here is some additional information you can provide to best support the BLE E2E experts when they return to office:

• Changes made to the default code example configuration
• Your CCSTUDIO version and Dependencies installed
• Any other screenshots, code snippets, or information which may prove useful.

Thank you for your patience and diligence during this time!

Regards,
Ryan

Hello Muthu,

Thanks for reaching out. Could you please point if you have modified the PDU size as well? This can be set inside SysConfig --> BLE --> General Configuration --> Max Size of PDU (bytes) and you would have to set it to at least 54 bytes. Please also consider that all connections will begin with a default MTU of 23 bytes. If secure connections is enabled, the local device will support an MTU of 65 (which is set by PDU size of 69 - MAX_PDU_SIZE - 4) by default., however he actual resulting MTU must still be negotiated via MTU exchange procedure using gatt exchange MTU command.

I would suggest to look into the following section of the User`s Guide: Configuring for Larger MTU Values.

BR,

David.

Hi David,

This is the configuration. The MTU exchange is happening when request from client, but without changing MTU the simple peripheral example was receiving 50bytes, I have changed default 16-bit Write characteristics(0xfff3) into custom characteristics(128-bit), and configured simpleProfileChar3Props = GATT_PROP_WRITE into simpleProfileChar3Props = GATT_PROP_WRITE_NO_RSP, after changing this I'm not able to receive more then 20 bytes without requesting the MTU from client device. But if client device request MTU, I'm able to receive more then 20 bytes.

Is there any difference between GATT_PROP_WRITE and GATT_PROP_WRITE_NO_RSP?

CCS version: 8.1.0

SDK version : 4.30.00.08

I'm in end of this project, kindly support as soon as possible.

Hello Muthu,

Expanding the UUID to a 128-bit one, it is normally done by a macro, so it shouldn't be an issue. Are you using the GATT_WriteNoRsp() function? Is there a reason for not using GATT_WriteCharValue()? Is the PDU size configured in both peripheral and central devices?

BR,

David.

Hi David,

I'm using GATT_WriteNoRsp().  Our requirement is to use GATT_WriteNoRsp(). I have configured PDU size in peripheral side, it is mentioned in Previously  and in central side they configured PDU size.

I'm configuring the Custom characteristics property with GATT_PROP_WRITE_NO_RSP(simpleProfileChar3Props =GATT_PROP_WRITE_NO_RSP).By using this configuration, not able to Receive more the 20byte from client device.

Regards

Muthuraj K

Hello Muthu,

I don't see why the GATT_WriteNoRsp() should behave differently in this case. In addition you confirmed the PDU in central and peripheral are 69. Do you have a Bluetooth sniffer to confirm a MTU exchange is not happening in the first scenario and compare when the device doesn't transmit more than 20 bytes? May I ask as well why the MTU exchange procedure is not an option?

Thanks.

David.

Hi David,

I have attached the logs for your reference. In this without changing MTU 50-byte transmission happening by using GATT_WriteCharValue(). 

May I ask as well why the MTU exchange procedure is not an option?

 In existing the customer module was working without exchanging MTU, so only we are trying to achieve that.

nRF Connect, 2024-05-23
MDL1234500000000 (0C:61:CF:A0:95:84)
V	18:07:11.126	Connecting to 0C:61:CF:A0:95:84...
D	18:07:11.126	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	18:07:11.276	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	18:07:11.276	Connected to 0C:61:CF:A0:95:84
D	18:07:11.313	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D	18:07:11.313	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11)
D	18:07:11.330	[Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)
I	18:07:11.783	Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
I	18:07:12.115	Connection parameters updated (interval: 47.5ms, latency: 0, timeout: 5000ms)
D	18:07:13.266	[Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_PIN (0)
D	18:07:21.031	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDED (12)
I	18:07:21.031	Device bonded
D	18:07:21.089	wait(1600ms)
V	18:07:22.695	Discovering services...
D	18:07:22.695	gatt.discoverServices()
D	18:07:22.732	[Callback] Services discovered with status: 0
I	18:07:22.732	Services discovered
V	18:07:22.748	Generic Access (0x1800)
- Device Name [R W] (0x2A00)
- Appearance [R W] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Generic Attribute (0x1801)
Device Information (0x180A)
- System ID [R] (0x2A23)
- Model Number String [R] (0x2A24)
- Serial Number String [R] (0x2A25)
- Firmware Revision String [R] (0x2A26)
- Hardware Revision String [R] (0x2A27)
- Software Revision String [R] (0x2A28)
- Manufacturer Name String [R] (0x2A29)
- IEEE 11073-20601 Regulatory Certification Data List [R] (0x2A2A)
- PnP ID [R] (0x2A50)
Unknown Service (e837d9a2-9c49-4493-9547-8e6918a59ca8)
- Unknown Characteristic [R W] (0000fff1-0000-1000-8000-00805f9b34fb)
   Characteristic User Description (0x2901)
- Unknown Characteristic [R] (0000fff2-0000-1000-8000-00805f9b34fb)
   Characteristic User Description (0x2901)
- Unknown Characteristic [W] (64aecb40-849a-44f1-934f-addc4b316423)
   Characteristic User Description (0x2901)
- Unknown Characteristic [N] (0000fff4-0000-1000-8000-00805f9b34fb)
   Client Characteristic Configuration (0x2902)
   Characteristic User Description (0x2901)
- Unknown Characteristic [R] (0000fff5-0000-1000-8000-00805f9b34fb)
   Characteristic User Description (0x2901)
D	18:07:22.748	gatt.setCharacteristicNotification(0000fff4-0000-1000-8000-00805f9b34fb, true)
V	18:07:32.580	Writing request to characteristic 64aecb40-849a-44f1-934f-addc4b316423
D	18:07:32.580	gatt.writeCharacteristic(64aecb40-849a-44f1-934f-addc4b316423, value=0x0A312F31323334353130367030306D32353030303031356B323530307A30314E455720594F524B2020414D4552494341200A)
I	18:07:32.921	Data written to 64aecb40-849a-44f1-934f-addc4b316423, value: (0x) 0A-31-2F-31-32-33-34-35-31-30-36-70-30-30-6D-32-35-30-30-30-30-31-35-6B-32-35-30-30-7A-30-31-4E-45-57-20-59-4F-52-4B-20-20-41-4D-45-52-49-43-41-20-0A
A	18:07:32.921	"(0x) 0A-31-2F-31-32-33-34-35-31-30-36-70-30-30-6D-32-35-30-30-30-30-31-35-6B-32-35-30-30-7A-30-31-4E-45-57-20-59-4F-52-4B-20-20-41-4D-45-52-49-43-41-20-0A" sent
V	18:07:54.762	Writing request to characteristic 64aecb40-849a-44f1-934f-addc4b316423
D	18:07:54.763	gatt.writeCharacteristic(64aecb40-849a-44f1-934f-addc4b316423, value=0x0A312F31323334353130367030306D32353030303031356B323530307A30314E455720594F524B2020414D4552494341200A)
E	18:08:00.127	Error 133 (0x85): GATT ERROR
D	18:08:00.127	[Callback] Connection state changed with status: 8 and new state: DISCONNECTED (0)
E	18:08:00.127	Error 8 (0x8): GATT CONN TIMEOUT
I	18:08:00.127	Disconnected
D	18:08:00.169	[Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED

Thanks,

Muthuraj K

Hi Muthuraj,

I understand you are looking at having the CC2640R2F device sending an MTU request.
May I kindly ask if you have reviewed the following piece of docs: https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gatt.html#maximum-transmission-unit-mtu 

As the CC2640R2F seems to behave as a GATT client, I guess you should use the GATT_ExchangeMTU() command.

I hope this will help,

Best regards,

Hi Clement,

Thanks for shared documents. For your information the CC2640R2F worked as peripheral(server), and i am using mobile phone (nrf connect as client).

is it possible to request MTU size to client from peripheral?

I have tried  GATT_ExchangeMTU(), but it's not working. i have attached the image for your reference.

My Query is After connection without exchanging MTU using this  GATT_WriteCharValue() property is able to write more than 20bytes but using GATT_WriteNoRsp() property I'm not able Write without exchanging MTU in TI simple peripheral example. Kindly support, I'm in end of this project.

Regards

Muthuraj k

Hello Muthuraj,

Thanks for the additional information.

Could you please help me clarify the following:

1. Are you using blestack or ble5stack from the SDK? Please use the ble5stack if this is not the case already.
2. The  GATT_ExchangeMTU() can only be initiated by the client and the MTU size will be chosen based on the proposed values of the peripheral and the central.
3. You mentioned you are using simple peripheral project running as a server (which the example does). But I assumed you were using another device configured as central (client) from where you are executing the GATT_WriteCharValue() and GATT_WriteNoRsp, as this can only be executed from the client. Could you please clarify on this?
4. Is this the nrf connect app then?

   Muthu raj said:

   upon enabling MTU request from the central device

   
   BR,

   David.

Hi David,

1. Are you using blestack or ble5stack from the SDK? Please use the ble5stack if this is not the case already.I'm using blestack from sdk version 4.30.00.08, and I also verified that the ble5stack works as like  blestack.

       3.You mentioned you are using simple peripheral project running as a server (which the example does). But I assumed you were using                      another device configured as central (client) from where you are executing the GATT_WriteCharValue() and GATT_WriteNoRsp, as this                   can only be executed from the client. Could you please clarify on this?

           I previously mentioned that I'm using simple peripheral project, and i configure the Write character property (0xfff3) as

             simpleProfileChar3Props =  GATT_PROP_WRITE into simpleProfileChar3Props = GATT_PROP_WRITE_NO_RSP.

            if I'm using GATT_PROP_WRITE, able to write(client to server) more than 20 bytes without exchanging MTU (not enabling  MTU from central device -nrf connect app).

            if using GATT_PROP_WRITE_NO_RSP not able to write more than 20 bytes. if changing MTU from central device (enabled MTU request from

             central - nrf connect app) able write more than 20 bytes. 

           our concern is there any difference between GATT_PROP_WRITE and GATT_PROP_WRITE_NO_RSP (showed in above image). If any                             difference by using GATT_PROP_WRITE_NO_RSP, then how to Write from client without exchanging MTU.

           In existing the customer module was works more than 20 bytes without exchanging MTU. So only We are trying to achieve it.

        Regards,

         Muthuraj K

Hello Muthuraj,

Could you please help me with the following:

1. Please try setting the properties to "GATT_PROP_WRITE_NO_RSP | GATT_PROP_WRITE". This in order to help root causing the issue and see if it can be used as a temporary work around.

2. In addition, have you modified the default PDU size? Try using HCI_LE_WriteSuggestedDefaultDataLenCmd() which sets the default maximum transmission packet size and the default maximum packet transmission time for the connection. This command should be inside SimplePeripheral_init() (commented out in the example).                   

       //Set initial values to maximum, RX is set to max. by default(251 octets, 2120us)
       #define APP_SUGGESTED_PDU_SIZE 251 //default is 27 octets(TX)
       #define APP_SUGGESTED_TX_TIME 2120 //default is 328us(TX)
       HCI_LE_WriteSuggestedDefaultDataLenCmd(APP_SUGGESTED_PDU_SIZE, APP_SUGGESTED_TX_TIME);

3. If you have a BLE sniffer at hand, could you please share the logs when using GATT_PROP_WRITE_NO_RSP vs GATT_PROP_WRITE? The logs you shared are the ones from the application if I am not mistaken and they do not provide much information. Additionally I see a GATT CONN TIMEOUT, is this on purpose? do you know the reason? There might be a MTU restriction coming from the central side, which is why a sniffer log could help us understand what can be happening on that side and who/why is restricting the MTU size.

BR,

David.

Hi David,

Thanks for the suggestion, We have tried changing the property as "GATT_PROP_WRITE_NO_RSP | GATT_PROP_WRITE" and "HCI_LE_WriteSuggestedDefaultDataLenCmd()". After changing this connect with the mobile(central) without exchanging MTU the server able to receive more than 20bytes in nrf connect app, and again connect with customer mobile app it's not working but, once I connect with customer mobile app and background NRF is connected with exchanging MTU it works fine and able to receive more than 20 bytes, and same think without MTU exchange connected with customer mobile app and in background we are able to write  more than 20 bytes from nrf  app parallelly. exactly we don't know the reason is any restriction on property. do you have any idea for the same? We requested the customer to enable the connection log from mobile app.

currently we don't have sniffer to take and share the logs. 

is it possible to take logs from BT tool or any other opensource? kindly suggest us.

Regards,

Muthuraj K

Hello Muthuraj,

Apologies, I am afraid I couldn't fully understand the current status. Could you please confirm this is the case:

• When you transmit data from central device (phone running nordics app), the cc26 (peripheral) is now able to receive the full amount of bytes (more than 20) without MTU exchange. However, this is not possible if you try the same with the customers mobile app (which is different from nordics app)?

Please help me clarifying this.

BR,

David.

Hi David,

The customer mobile application was different, but we checked for verification purpose if its working or not.  And the same time previously I asked, is there any difference between GATT_PROP_WRITE_NO_RSP and GATT_PROP_WRITE. could you please help me for this?

And I have shared a Log (Nordic app) after changing Your Suggestions.

nRF Connect, 2024-05-28
MDL0123456789000 (0C:61:CF:A0:95:84)
V 15:35:45.903 Connecting to 0C:61:CF:A0:95:84...
D 15:35:45.903 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D 15:35:46.704 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I 15:35:46.704 Connected to 0C:61:CF:A0:95:84
D 15:35:46.738 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D 15:35:46.761 [Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11)
D 15:35:46.762 [Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)
I 15:35:47.177 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
I 15:35:47.491 Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 5000ms)
D 15:35:50.075 [Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_PIN (0)
I 15:35:53.159 Connection parameters updated (interval: 15.0ms, latency: 0, timeout: 6000ms)
D 15:35:57.286 [Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDED (12)
I 15:35:57.286 Device bonded
D 15:35:57.319 wait(1600ms)
V 15:35:58.936 Discovering services...
D 15:35:58.936 gatt.discoverServices()
D 15:35:58.957 [Callback] Services discovered with status: 0
I 15:35:58.957 Services discovered
V 15:35:58.972 Generic Access (0x1800)
- Device Name [R W] (0x2A00)
- Appearance [R W] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Generic Attribute (0x1801)
Device Information (0x180A)
- System ID [R] (0x2A23)
- Model Number String [R] (0x2A24)
- Serial Number String [R] (0x2A25)
- Firmware Revision String [R] (0x2A26)
- Hardware Revision String [R] (0x2A27)
- Software Revision String [R] (0x2A28)
- Manufacturer Name String [R] (0x2A29)
- IEEE 11073-20601 Regulatory Certification Data List [R] (0x2A2A)
- PnP ID [R] (0x2A50)
Unknown Service (e837d9a2-9c49-4493-9547-8e6918a59ca8)
- Unknown Characteristic [W WNR] (64aecb40-849a-44f1-934f-addc4b316423)
   Characteristic User Description (0x2901)
- Unknown Characteristic [N] (b792a4bb-db87-436a-9066-db63c5fb3f00)
   Client Characteristic Configuration (0x2902)
   Characteristic User Description (0x2901)
- Unknown Characteristic [W] (f535dd6e-7975-4abd-9719-491e38a81179)
   Characteristic User Description (0x2901)
- Unknown Characteristic [I] (36e8614b-2ded-45c1-9ad3-c9f59a01f21e)
   Client Characteristic Configuration (0x2902)
   Characteristic User Description (0x2901)
D 15:35:58.972 gatt.setCharacteristicNotification(b792a4bb-db87-436a-9066-db63c5fb3f00, true)
D 15:35:58.973 gatt.setCharacteristicNotification(36e8614b-2ded-45c1-9ad3-c9f59a01f21e, true)
V 15:36:17.332 Writing request to characteristic 64aecb40-849a-44f1-934f-addc4b316423
D 15:36:17.332 gatt.writeCharacteristic(64aecb40-849a-44f1-934f-addc4b316423, value=0x0A312F31323334353130367030306D32353030303031356B323530307A30314E455720594F524B2020414D4552494341200A)
I 15:36:17.448 Data written to 64aecb40-849a-44f1-934f-addc4b316423, value: (0x) 0A-31-2F-31-32-33-34-35-31-30-36-70-30-30-6D-32-35-30-30-30-30-31-35-6B-32-35-30-30-7A-30-31-4E-45-57-20-59-4F-52-4B-20-20-41-4D-45-52-49-43-41-20-0A
A 15:36:17.448 "(0x) 0A-31-2F-31-32-33-34-35-31-30-36-70-30-30-6D-32-35-30-30-30-30-31-35-6B-32-35-30-30-7A-30-31-4E-45-57-20-59-4F-52-4B-20-20-41-4D-45-52-49-43-41-20-0A" sent

Regards

Muthuraj K

Hi David,

I have tested with this BT tool.

1. In BT tool if select the  GATT_WriteNoRsp() attribute to Write more than 20 bytes, it's not success due to MTU limitation. It is showing invalid MTU size.

2. And also select GATT_WriteCharValue() attribute, it is also showing invalid MTU size.

3. before use those two properties, if exchange the MTU size from BT tool, the GATT_WriteNoRsp() and GATT_WriteCharValue() attributes to able to write more than 20 bytes (From BT tool to peripheral).

4. If Using GATT_WriteLongCharValue() attribute, I'm able to Write more than 20 bytes without exchanging MTU size.

I hope same is happening in customer mobile app. In customer mobile app using  GATT_WriteNoRsp() attribute.

Regards

Muthuraj K

Hello Muthuraj,

A packet sniffer that you can leverage is the SmartRF Packet Sniffer, which is a software application that can display and store radio packets captured by a listening RF device. It may not be able to give very detailed information about what is happening over the air (as other specialized tools do), but it will be a start to see what commands the central device is transmitting and how the peripheral is answering.

Regarding the Btool tests (thanks for sharing this). There shouldn't be any difference between GATT_WriteNoRsp() and GATT_WriteCharValue() when it comes to the MTU size. In both cases, a MTU exchange is required, which is why I wanted to see with the ble logs if sending more than 20 bytes without MTU exchange is possible with GATT_WriteCharValue() as I don't expect it to be.

Could you confirm what type of GATT write command is the customer mobile app running? (GATT_WriteLongCharValue, GATT_WriteNoRsp, GATT_WriteCharValue, for instance)

Muthu raj said:

After changing this connect with the mobile(central) without exchanging MTU the server able to receive more than 20bytes in nrf connect app,

Does this means that the peripheral is able to receive more than 20 bytes without MTU exchange?

BR,

David.

Hi David,

Before I tested with BT tool, I have tested With Nordic Mobile app, which is transmitting more than 20bytes, exactly don't know which attribute they are using (Nordic mobile app).

But after testing with BT tool, I understood Without exchanging the MTU, it is not possible to Write more than 20 bytes (from Central to Peripheral) while using GATT_WriteNoRsp() or GATT_WriteCharValue().

I requested to the customer, which attribute they are used in mobile app. They confirmed GATT_WriteNoRsp() attribute has been using.

How to achieve, receiving more than 20 bytes form central?

Regards

Muthuraj K

Hi David,

How to achieve, receiving more than 20 bytes form central?

Is there any update regarding this? 

Kindly do support to resolve this Issue, we are in end of this project.

Regards

Muthuraj K

Hello Muthuraj,

Considering the two cases you are mentioning, it seems like the NRF app is using some type of GATT_WriteLongCharValue() function if the amount of characters that are required to be send are more than the minimum, which is not the case for the customer app. The GATT_WriteLongCharValue() (which is TI developed) executes the task of splinting the data in several packets of 23 bytes (approx) in order to send them separately. Therefore, I would assume a similar task is being executed by the central side (NRF app) and NOT by the customer app (executing only GATT_WriteNoRsp() - 23 bytes). This behaviour is established by the Bluetooth Spec.

BR,

David.

Hi David,

Based on your reply, I can understand below points, please confirm if I am wrong,

1. GATT_WriteLongchar() function is applicable for TI chipset. here we can fragmentation the bytes more than 23 if device is it in central.

2. BLE spec default MTU size is 23 bytes.

3. The default MTU is 23 bytes and can be increased to 247 bytes. When increasing this value longer payloads can be achieved by sending several packets for one transaction. how to achieve on our Peripheral-chipset? please suggest. 

we are longing the answer don't stretch the time. customer asking whether it is possible or not? we are final call for production. I hope you are understanding our position.

Regards,

Muthuraj K

Hello Muthuraj,

1. The GATT_WriteLongchar() function is implemented in the SDK and can be used by the central device to send data with size grater than the set MTU by fragmenting the packets and sending them separately. Please consider again that this logic is implemented by the central (has to be implemented by the mobile app in your case).
2. By default, LE devices assume the size of the L2CAP PDU is 27 bytes, which corresponds to the maximum size of the LE packet that can transmit in a single connection event packet. The data length extension feature allows the LE controller to send data channel packet data units (PDUs) with payloads of up to 251 bytes of application data. If prior to the connection, the suggested MTU size are set to the defaults for both TX and RX (27 bytes) then the CC2640R2 will not initiate a data length exchange. If before the connection, the MTU size are not default, then the device will negotiate a payload size for data channel PDUs. In any case, a MTU exchange/negotiation needs to happen. Please see section Utilizing DLE in the Application.

BR,

David

Hi David,

I could understand from your commands

1. BLE Stack will not support to data length extension feature for peripheral.

2. BLE5 Stack will supports to data length extension feature for peripheral if Client has not set by the default MTU Size. this will supports > 20 bytes transfer the data without MTU exchange. Please confirm. 

I will try with BLE5stack.

Regards,

Muthuraj.

Hello Muthuraj,

Both BLE5stack and BLEstack support the same mechanism and therefore need to go through a MTU exchange process. This is specified by the Bluetooth Specs, please see section 4.3.1 Exchange MTU of Core Specification 5.0. Both central and peripheral cannot know what is the MTU size for communication if no exchange/negotiation has been done, so the minimum will be assumed. What I mentioned is that it is possible that the NRF app is managing GattWrite commands that are longer than the default MTU size (23 bytes) by fragmenting them and sending them in separate packets, received by the peripheral. This process does not require a MTU exchange, as the central will work with the minimum size.

Overall, the MTU will be minimum between MTU size of Central and MTU size of peripheral. By default it will be 23. More than 23 means that the client should send an MTU exchange request to the server. If MTU size is 23 , and you want to send more than 23 bytes, Write-long/read long procedures should be used.

BR,

David.