Dave, you are very wishy washy with your information. Effectively, you are telling us that all the code is correct on both sides of the equation, but it fails.
If you were me or Patryk, what would you be thinking? Would you think "I need 100% of the info and all the code to see if I can find the problem cause"?
It would be good to know the exact devices involved too. Make, model, BLE version.
In Bluetooth 4.0, BLE was introduced with a maximum payload of 33 bytes (not including Access Address and CRC fields). Each layer in the protocol stack takes its cut:
2 bytes for packet header (type and length),
4 bytes for MIC (when encryption is enabled),
4 bytes for L2CAP header (channel ID and packet length),
ATT protocol is left with 23 bytes, which is the default and minimal MTU for ATT protocol.
With an ATT write request (or notification), 3 bytes are used by command type and attribute ID, 20 bytes are left for the attribute data.
At the ATT level, this limit may be enlarged in two ways:
Using fragmentation at the L2CAP level:
L2CAP will split ATT PDUs in 27 bytes fragments (23 for the first one).
Drawbacks:
It needs memory on both sides,
It is less reliable as packets may get lost by some implementation (even if spec do not speak about packet loss at the L2CAP level, it happens)
Using packet length extension introduced in Bluetooth 4.2:
Up to 251 bytes at the radio level (255 with MIC), so 242 bytes available for attribute data.
Drawbacks:
Still new, needs hardware support, so not implemented everywhere (even if announcing BLE 4.2 support),
Packet with longer airtime will have more chances of getting jammed, so longer packets implies more retransmissions.
If both methods are used, L2CAP may use bigger fragments.
Whatever low-level splitting of ATT PDU, Attribute value length is limited to 512 by 3.F 3.2.9.
https://docs.espressif.com/projects/espressif-esp-faq/en/latest/software-framework/ble-bt.html
- By default, the MTU size of ESP32 Bluetooth LE is 23 bytes, and can be configured to reach 517 bytes.
- For phones, the MTU size can be self-defined. Then, the end device with a smaller MTU will be chose for communication.
If you increased the mtu limit correctly, maybe the extension mtu block only works properly with ble 5.0. I don't know if anyone has managed to test this block.
SDK and recognized of the device
I can not find the sdk, but I assume that the device is recognized because it's boonded and beyond the ble permissions in the android coding. I actualy recieve data soo the way of communication is not the problem.
MTU size
- Requests a new minimum transmission unit (MUT) for the BluetoothLE connection. This feature
- is only supported when both devices support Bluetooth 4.2 or higher. If the MTU is changed
- successfully, the MTUChanged event will be run. The default MTU is 20.
- This block is intended for advanced apps that need to change the size of the messages sent
- between the BLE devices. Most developers will not need to adjust this value.
The datasheet tells me thate it the protocol is "Bluetooth v4.2 BR/EDR and BLE specification"
Datasheet esp32 wroom
- The MTUChanged event is run when the two BluetoothLE devices have successfully changed their
- maximum transmission unit (MTU) to a different value. This event will only run in response
- to a call to the method block RequestMTU.
I have serial logged the esp after the request is made in the app like described above and it remains 255 like specified in the nimconfig.h file and the changeMTU procedure tels me 128. If it is addapted in the app it would be ok for me. But Is that enough? I don't know. I did some tests by setting them fix too 128 in the app and the shetch. The result I get is a string of 2 char longer than 20bytes.
Dave, you are very wishy washy with your information. Effectively, you are telling us that all the code is correct on both sides of the equation, but it fails.
Well I assume that the shetch works because it worked on one of the versions "bluetoothLE" extension. What I can do is repeat what I have done yesterday and findout how I made it work. I just want too use the latest deployment. That's why I mad this topic.
I have succesfull repeat what I have done yesterday. You don't have too fix you on the MTU request. I will report as soon as possible. I think you have to make a new procedure. My knowledge of programming extensions is not enough. Soo I would be glad if someone that can make the upgrade offical.