Hi Dave
What baud rate have you set in the esp32's Sketch? Has anything been changed in the Sketch since your App Inventor BLE Extension upgrade?
Well idd, something strange happened. First the old version didn't send the long string. I update to get rid of that problem and it worked, but now it the opposite. After changing from BLE to NimBLE in the arduino it appeared it didn't work anymore. So I looked what the problem was. It surely not the program from the esp. So I looked in what I changed and I tried the old extension back and it worked. 
I checked with two shetches and I get the same input. for me the latest extension is 08-'20 on the link.
I did a look-up first and watched al the topics about it but it didn't work for me. It's not a serial Bluetooth anymore, it is a secure Bluetooth server that I'm working on.
Ater a night... this morning I checked again my latest version in the ais and now it is Extension Version: 20181124 and version 2.0... I'am sure I imported the 08-'20 version. I have it in my downloads and I checked it yesterday.
When I'm now opening my projects I get this.
The two ais files are scrumbled again. And I did make a save before closing down. I have only problems with this ias
https://community.appinventor.mit.edu/t/ble-esp32-bluetooth-send-receive-arduino-ide/1980/3
App send text to ESP32. Show on the Serial Monitor.
You imported a version that does not have the gray blocks. Remove gray blocks or import the latest version.
Thanks for the reply. I know that. I just maked a new project without updating 2 versions up in once, but I still cann't recieve the whole string on the other side without doing an MTU request in the app.
I did an MTU request like this and I'm now recieving
[/very very very very
this instead of
[/very very very ver
It is still not complete
I don't know what I am doing wrong to make the request and the esp is also set to 255bytes.
Try this. You can install it over the latest release you have, but save a backup first!
Note, it's not an official release (but close I think).
edu.mit.appinventor.ble.aix (178.3 KB)
Dear, I tried it but I it still too short. I have made a new project and I recieve this on the other end.
�Starting NimBLE Server
Advertising Started
Connected
Server PassKeyRequest
Starting BLE work!
[This is a long string
Disconnected
Connected
Starting BLE work!
[This is a long string
Disconnected
Ble_23_04_2021.aia (174.5 KB)
I notest that non ble devices that doesn't Advertising are not displaying the devicename right and are not able too connect too the app.
That is to be expected, the only similarity between Classic and Light Edition is the name.
Can you post your Sketch here?
This is the shetch I made. It's not finished, but it suppose to work on a esp32 lua after installing the board. It probebly will work on other boards to.
/*
Name: ESP32_smallBLE_Bluetooth.ino
Created: 4/22/2021 3:25:21 AM
Author: Dave Moon
/
#include <NimBLEDevice.h>
// See the following for generating UUIDs:
// https://www.uuidgenerator.net/
#define SERVICE_UUID "4fafc201-1fb5-459e-8fcc-c5c9c331914b"
#define CHARACTERISTIC_UUID "beb5483e-36e1-4688-b7f5-ea07361b26a8"
#define PASSKEY 123456
NimBLEServer pServer = NULL;
NimBLECharacteristic* pCharacteristic = NULL;
bool deviceConnected = false;
bool oldDeviceConnected = false;
String StrRecieved;
class MyServerCallbacks : public NimBLEServerCallbacks {
void onConnect(NimBLEServer* pServer) {
deviceConnected = true;
NimBLEDevice::startAdvertising();
Serial.println("Connected");
};
void onDisconnect(NimBLEServer* pServer) {
deviceConnected = false;
NimBLEDevice::startAdvertising();
Serial.println("Disconnected");
}
uint32_t onPassKeyRequest() {
Serial.println("Server PassKeyRequest");
return PASSKEY;
}
bool onConfirmPIN(uint32_t pass_key) {
Serial.print("The passkey YES/NO number: "); Serial.println(pass_key);
return true;
}
void onAuthenticationComplete(ble_gap_conn_desc* desc) {
if (!desc->sec_state.encrypted) {
NimBLEDevice::getServer()->disconnect(desc->conn_handle);
Serial.println("Encrypt connection failed - disconnecting client");
return;
}
Serial.println("Starting BLE work!");
}
};
class CharacteristicCallbacks : public NimBLECharacteristicCallbacks {
void onWrite(NimBLECharacteristic* pCharacteristic) {
std::string value = pCharacteristic->getValue();
Serial.println(pCharacteristic->getValue().c_str());
}
};
void setup() {
Serial.begin(115200);
Serial.println("Starting NimBLE Server");
NimBLEDevice::init("NimBLE-Arduino");
//NimBLEDevice::setMTU(120);//128bytes
/** Optional: set the transmit power, default is 3db /
NimBLEDevice::setPower(ESP_PWR_LVL_P9); /* +9db /
NimBLEDevice::setSecurityAuth(true, true, true);
NimBLEDevice::setSecurityPasskey(PASSKEY);
NimBLEDevice::setSecurityIOCap(BLE_HS_IO_DISPLAY_ONLY);
pServer = NimBLEDevice::createServer();
pServer->setCallbacks(new MyServerCallbacks());
NimBLEService pService = pServer->createService(SERVICE_UUID);
NimBLECharacteristic* pCharacteristic = pService->createCharacteristic(CHARACTERISTIC_UUID, NIMBLE_PROPERTY::WRITE | NIMBLE_PROPERTY::WRITE_ENC | NIMBLE_PROPERTY::WRITE_AUTHEN);
pCharacteristic->setCallbacks(new CharacteristicCallbacks());
pService->start();
NimBLEAdvertising* pAdvertising = NimBLEDevice::getAdvertising();
pAdvertising->addServiceUUID(SERVICE_UUID);
//pAdvertising->setScanResponse(true);
pAdvertising->start();
Serial.println("Advertising Started");
//Serial.println(NimBLEDevice::getMTU());
}
void loop() {}
Well, the most important part we cannot see, what happens in the loop() to receive strings? However, the Characteristic UUID has not been defined for read, only write?
They are handled in callbacks, and my code calls further on the library. It simular like and interrupt. When something is received it runs it. And yeah it is strange that it is write, I nothest that to. I will test it with read. I let you know.
Nope, it doesn't work at all on read. I have looked in other examples and they do it the same way.
I looked in they documentation and now I understand. It Allows reading and writing values to the characteristic.
I have done it on an a different esp32 and put a delay in the loop to get more breath for the esp. It diden't change the outcome. On which SDK is this extension based?
The extension is opensource. If you know Jave, you can customize them.
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
How to certify the MTU size of ESP32 Bluetooth® LE?
- 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.