Hello dears,
I'm newbie here and trying to send big strings, like 128bytes from the app to my hardware(ESP32).
From the app side I have a text box that is sending the string to ESP32, all working except when I try to send strings over 23bytes. Ok, I read some topics here and tried to apply those solutions but no success yet.
From my ESP32 firmware I wrote:
BLEDevice::init("Monitor3");
BLEDevice::setMTU(128);
uint16_t MTUU = BLEDevice::getMTU();
Serial.print("MTU --> ");
Serial.println(MTUU);
I am using the latest BLE extension and my cellphone has BLE V5.0
PLease how can I proceed at app side?
Thanks in advance
See
Hello ABG, thanks for your fast help.
I saw that topic but in my case my device esp32 has BLE V 4.2 and the cellphone V5.0, I would like to send entire String. Do you know where I can find an example please?
Regards
I would try using the board's search facility on the text 'esp32'.
That combo fits the requirement for increasing the MTU so how about experimenting with that?
That needs to be greater than 128 as BLE uses some of the bytes for the packet's header and footer. Set it to 192 bytes, and the same at the App end (via BLE MTU Block).
Ok, thanks for your help
I'm searching since yesterday for some examples, think will find soon.
Hello, thanks for help me.
Yes, I bougth my board(Heltec ESP32 + Lora) because is a good option to my home projects.
Just tried with MTU = 192:
At serial monitor I am still receiving that limitation for 23bytes.
From ESP32:
BLEDevice::setMTU(192);
From app:
Am I wright?
That event block looks like an unlikely place to request an MTU change.
From the name of the event, I imagine it is confirming the success of the attempt to change the MTU that you did not yet submit (a temporal anomaly)
Here is the doc page:
http://iot.appinventor.mit.edu/#/bluetoothle/bluetoothleintro
Here is the doc for the event:
-
MTUChanged
– 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. Parameters :-
bytes
( number ) — The new size, in bytes, of the new MTU.
-
Here is the doc for the request MTU block:
-
RequestMTU
– 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. Parameters :-
bytes
( number ) — The desired MTU size.
-
So from the docs, you have done this completely backwards.
Just ask for the 192 MTU in AI2, and start transmitting after you got the event that tells you both sides can handle the 192 size.
You right, I wrote completetly backwards.
Now I separated like this:
Now I can see the device at the BLE list but can't conect.
I'm still learning about this platform and don't know if what I'm doing is correct or better option.
Thanks one more time
After a lot of hours I found the problem in my app.
How I proceeded:
1- At ESP32 code I put this line: BLEDevice::setMTU(192);
2- At app I put the call Request MTU on the .Connected block asking for the same 192 bytes;
In my case, when I have to send a payload < 23 bytes I can use the call .WriteStrings like a lot of examples but if i need to send more than 23bytes I am using the call .WriteBytes
Thanks a lot for your help and patience guys
@ewpatton i mentioned this bug a year (or more) ago.
WriteStrings is fixed to 23 Bytes and WriteBytes uses MTU.
until now it is not fixed.
Very interesting, I didn't know about this restriction/bug.
Like I said, in my case this "discovery" solve my problem. So should I unmark like solved?
You solved it with your workaround, so no need to unmark as a solution, you found a solution to your issue
(added to FAQ)
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.