gohai commented 6 years ago

I am using the BluetoothSerial::write() method to send single bytes to the host computer. I have discovered that when I am sending more that ~ 32 bytes at a time, the ESP will silently drop the additional bytes. Adding a delay(10); after each byte fixes this for me, but this is only a stop-gap solution.

Oddly, esp_spp_write does return ESP_OK even when it is dropping bytes, so I believe there is a real bug here.

I am running arduino-esp32 at c63d746a069103ccb9f6afd35fa5a21e73f1340a, with an rebuilt libbt.a that has a COD set so that macOS will accept the SPP device (but no other changes).

gohai commented 6 years ago

Pinging @copercini

lyusupov commented 6 years ago

@gohai:

when I am sending more that ~ 32 bytes at a time, the ESP will silently drop the additional bytes

could you, please, double check ?

I am sending NMEA strings over SPP (> 32 bytes) and everything is fine to me with current Core ( IDF aaf1239 ).

gohai commented 6 years ago

@lyusupov

I'll double check tomorrow - but I am very certain that I saw it with the previous core (before aaf1239) yesterday.

I saw this using the Firmata library, which uses BluetoothSerial::write(uint8_t), to transmit large ("SYSEX") messages. Logging all the bytes that are passed through write on the UART, I saw all of them - but on the receiver-side I was missing bytes > ~ 37. Oddly, esp_spp_write always returned ESP_OK still. And this started working when I added a delay(10); after each byte sent out.

So, my guess is that there is a certain limit of outstanding bytes to be transmitted over SPP. Perhaps your connection was stronger, so there was less of a backlog? Or perhaps it matters whether you queue multiple bytes at once, or one-by-one (which was what this Firmata library was doing).

gohai commented 6 years ago

@lyusupov

I just double checked with the new core - still seeing this issue!

copercini commented 6 years ago

@gohai do you have some code that I can reproduce this issue here?

gohai commented 6 years ago

Sure - this demonstrates it clearly

#include "BluetoothSerial.h"
BluetoothSerial SerialBT;
static uint32_t last_send = 0;

void setup() {
  SerialBT.begin("ESP32test");
}

void loop() {
  uint32_t now = millis();

  if (SerialBT.hasClient()) {
    if (5000 < now-last_send) {
      for (uint8_t i=0; i < 52; i++) {
        SerialBT.write('A'+(i % 26));
      }
      last_send = now;
    }
  }

  delay(1);
}

This is what I received (I added line breaks to increase readability):

A
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTU
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ATUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRST
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ

lyusupov commented 6 years ago

I can confirm that:

$ time cat /dev/rfcomm0
DEABCFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ

copercini commented 6 years ago

I can confirm too, it's triggering ESP_SPP_CONG_EVT sometimes that is a congestion event

[I][BluetoothSerial.cpp:59] esp_spp_cb(): ESP_SPP_INIT_EVT
[I][BluetoothSerial.cpp:74] esp_spp_cb(): ESP_SPP_START_EVT
[I][BluetoothSerial.cpp:99] esp_spp_cb(): ESP_SPP_SRV_OPEN_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT
[V][BluetoothSerial.cpp:95] esp_spp_cb(): ESP_SPP_WRITE_EVT

beegee-tokyo commented 6 years ago

I have a project where we (crazy as we are) try to send a short message like 89534,65200 every 5 ms over BluetoothSerial to a terminal. The result is many many many lost messages. My problem is not the lost messages, but that BTSerial.write() does NOT report any error about it! I can live with the problem and pause sending or resend data if I only would know that the error occured.

I made a small test sketch were I start sending every 100ms, then every 66ms and so on down to every 5ms. Here is the log result:

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:11584
entry 0x40078a60

Jul  4 2018 16:09:03
Version: 0.0.1

Sending raw data continously

initBlueTooth()
initBLE()
[D][BLEDevice.cpp:430] setPower(): >> setPower: 7
[D][BLEDevice.cpp:435] setPower(): << setPower
Bluetooth MAC: 24:0A:C4:81:CE:9E
Bluetooth Serial initialized
[I][BluetoothSerial.cpp:59] esp_spp_cb(): ESP_SPP_INIT_EVT
[I][BluetoothSerial.cpp:74] esp_spp_cb(): ESP_SPP_START_EVT
btSppTask loop started
Start with sps of 10
[I][BluetoothSerial.cpp:99] esp_spp_cb(): ESP_SPP_SRV_OPEN_EVT
Switched to sps of 20
Switched to sps of 40
Switched to sps of 50
Switched to sps of 66
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
Switched to sps of 100
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
Switched to sps of 200
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
Switched to sps of 10
[I][BluetoothSerial.cpp:92] esp_spp_cb(): ESP_SPP_CONG_EVT
Switched to sps of 20
E (59308) BT: port_rfc_closed RFCOMM connection in state 2 closed: Closed (res: 19)
Errorcnt on this session: 0
[I][BluetoothSerial.cpp:71] esp_spp_cb(): ESP_SPP_CLOSE_EVT
E (59317) BT: rfc_find_lcid_mcb LCID reused LCID:0x41 current:0x0
E (59320) BT: RFCOMM_DisconnectInd LCID:0x41

copercini commented 6 years ago

This effect seems gone writing all data with one SerialBT.write() or SerialBT.println call, and not byte by byte I know, it's not a solution, just a workaround

#include "BluetoothSerial.h"
BluetoothSerial SerialBT;
static uint32_t last_send = 0;
unsigned char testData[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

void setup() {
  SerialBT.begin("ESP32test");
}

void loop() {
  uint32_t now = millis();

  if (SerialBT.hasClient()) {
    if (5000 < now-last_send) {
        SerialBT.write(testData, 26); //buffer, size
      last_send = now;
    }
  }
  delay(1);
}

or with println:

#include "BluetoothSerial.h"
BluetoothSerial SerialBT;
static uint32_t last_send = 0;

void setup() {
  SerialBT.begin("ESP32test");
}

void loop() {
  uint32_t now = millis();

  if (SerialBT.hasClient()) {
    if (5000 < now-last_send) {
        SerialBT.println("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
      last_send = now;
    }
  }
  delay(1);
}

beegee-tokyo commented 6 years ago

@copercini I like workarounds. Will try tomorrow and give feedback.

beegee-tokyo commented 6 years ago

@copercini , tried it and the first one worked for me, together with a reduction of the sending frequency. Instead of 1 packet every 5ms we send now a bundle of 10 packets every 50ms. That worked at least for a quick test this afternoon.

beegee-tokyo commented 6 years ago

Update: As I couldn't get my customers project to work as expected, I moved from using Arduino-ESP32 framework to a pure ESP-IDF project using the latest version of ESP-IDF. Using the bt_spp_acceptor example (which source code is very much the same as BTSerial Arduino code) I got it running without any drop of bytes even at an update rate of 8ms. So (just guessing, no prove) the problem might be within the ESP-IDF version that Arduino-ESP32 uses (precompiled) and the latest ESP-IDF version. Or within sdkconfig, which I set to give Bluetooth a higher priority than WiFi. Another test I did was to use BlueKirchens BTstack which gave me even better performance (time to perform a BTSerial write operation) than Espressifs Bluedroid implementation.

Just informing here, no blaming or complaining!

me-no-dev commented 6 years ago

You need to factor in your application design also. If you for example use bt serial in the loop and have other threads running on core 1, it's totally possible that the loop does not get to run often enough. If the code is the same, there should not be any performance difference between Arduino and IDF. Since it's totally fine to compile IDF code inside Arduino, can you try your "pure ESP-IDF" code in Arduino and see what happens? use setup() as app_main()

beegee-tokyo commented 6 years ago

@me-no-dev You are correct, deeper investigation (like enabling the correct debug log level in ESP-IDF ) showed that the performance of the ESP-IDF BTSerial is as bad as the Arduino-ESP32 BTSerial. Didn't actually expect a difference, because the source codes are basically the same. Where I hoped to get a difference was that in ESP-IDF I can change the load balance between WiFi and Bluetooth in the menuconfig. But even selecting to prioritize Bluetooth didn't help. What is really surprising is that with Bluekitchens BTstack I don't see lost characters or lost packages. They did a really good job.

copercini commented 6 years ago

as I understood of IDF API when it gets an ESP_SPP_CONG_EVT you should stop writing immediately to not lose data

The problem is that we don't know when it's available again, if it were possible to know that would be easy to make it stop writing when you received an ESP_SPP_CONG_EVT event and allow to write again it when you received an ESP_SPP_AVAILABLE_EVT event for example

Or even easy, get some bad answer from esp_spp_write() when it is congested

a bit off topic, @beegee-tokyo do you know how many heap is Bluekitchens BTstack using?

beegee-tokyo commented 6 years ago

Actually, thats what I did to detect write errors and congestions. I added flags that reflect the cong status and on next write request I return an error. According to the doc I found the congestion event is called every time the congestion status changes. Did not check that out, because my customer is pressuring and I moved on with BTstack for now.

Will check for heap usage tomorrow and report back.

copercini commented 6 years ago

@beegee-tokyo could you try with the attached libbt.a ? here at least the code provided by @gohai here is running fine now, without any ESP_SPP_CONG_EVT

extract it in the folder esp32\hardware\esp32\1.0.0-rc3\tools\sdk\lib libbt.zip

beegee-tokyo commented 6 years ago

@copercini just to confirm, thats to be applied to Arduino-ESP32? And where can I find the changes that @gohai did? Want to try the same in ESP-IDF and if it works submit a merge request.to ESP-IDF (or better, @gohai does) Falls es funktioniert, vielen Dank @gohai und Du solltest Deine Änderungen direkt an Espressif senden.

copercini commented 6 years ago

yes, it's for arduino... but for IDF you can just comment this line https://github.com/espressif/esp-idf/blob/be81d2c16d7f4caeea9ceb29fece01510664caf3/components/bt/bluedroid/stack/rfcomm/rfc_utils.c#L468 (tip from Markus Becker on esp32 forum) and should work

beegee-tokyo commented 6 years ago

@copercini all below is done on ESP-IDF app without Arduino (not even as a component) I tried the change in rfc_utils.c. Still getting congestions, but not as much. My guess is the first directly after connection is because I try to send 7 to 10 messages very fast, because I get a lot of data out of the sensors fifo. The ESP_SPP_WRITE_EVT error = 1 is my own log output. Error 1 means just generic failure without any further explanation.

Bluedroid output while sending to client

I (8002) MAIN: ESP_SPP_SRV_OPEN_EVT
E (8002) MAIN: Free heap after BT client connect: 142756

E (8032) MAIN: ESP_SPP_CONG_EVT
E (8032) MAIN: ESP_SPP_WRITE_EVT error 1
E (8032) MAIN: ESP_SPP_WRITE_EVT error 1
...
40 times E (8082) MAIN: ESP_SPP_WRITE_EVT error 1
...
E (8172) MAIN: ESP_SPP_WRITE_EVT error 1
E (8182) MAIN: ESP_SPP_CONG_EVT
E (9632) MAIN: ESP_SPP_CONG_EVT
E (9632) MAIN: ESP_SPP_WRITE_EVT error 1
E (9632) MAIN: ESP_SPP_WRITE_EVT error 1
W (9632) BT_RFCOMM: port_rfc_closed RFCOMM connection in state 2 closed: Closed (res: 19)
I (9642) MAIN: ESP_SPP_CLOSE_EVT
E (9642) MAIN: Free heap after BT client disconnect: 131676

BTstack output while sending to the client:

SPP_SERVER: Free heap after BT client connect: 175684
[1B][0m
[00:00:24.609] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 6
[00:00:24.626] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 8
[00:00:24.697] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 6
[00:00:24.713] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 8
[00:00:24.787] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 6
[00:00:24.869] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 6
[00:00:24.886] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 8
[00:00:24.906] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 9
[00:00:24.957] LOG -- rfcomm.c.2149: rfcomm_send_internal: l2cap cannot send now
[00:00:24.965] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 6
[00:00:25.065] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 6
[00:00:25.075] LOG -- rfcomm.c.2149: rfcomm_send_internal: l2cap cannot send now
[00:00:25.081] LOG -- rfcomm.c.1301: RFCOMM data UIH_PF, new credits: 6, now 10
[00:00:25.130] LOG -- rfcomm.c.193: RFCOMM_EVENT_CHANNEL_CLOSED cid 0x03
SPP_SERVER: RFCOMM channel closed
SPP_SERVER: Free heap after BT client disconnect: 175564

I can see very rare the rfcomm.c.2149: rfcomm_send_internal: l2cap cannot send now which obviously is comparable with the congestion situation we see on BlueDroid.

Regarding the heap usage of BTstack, here are some measurements done with BTstack and BlueDroid. Each time I connected/disconnected a client 3 times to see how the heap changes. One comment about BTstack: If using BTstack, you don't have app_main(), BTstack is using its own app_main(), doing some initialization stuff there and then call the "app_main" of my code. BTstack first run

Free heap at start of app_main: 192144
SPP_SERVER: Free heap at start of btstack_main: 188480
SPP_SERVER: Free heap after BT setup: 182368
SPP_SERVER: Free heap after I2C setup: 179532
SPP_SERVER: Free heap after BT client connect: 175564
SPP_SERVER: Free heap after BT client disconnect: 175564
SPP_SERVER: Free heap after BT client disconnect: 175684
SPP_SERVER: Free heap after BT client connect: 175704
SPP_SERVER: Free heap after BT client disconnect: 175704
SPP_SERVER: Free heap after BT client connect: 175704
SPP_SERVER: Free heap after BT client disconnect: 175704

BTstack second run

Free heap at start of app_main: 192144
SPP_SERVER: Free heap at start of btstack_main: 188480
SPP_SERVER: Free heap after BT setup: 182368
SPP_SERVER: Free heap after I2C setup: 179532
SPP_SERVER: Free heap after BT client connect: 175556
SPP_SERVER: Free heap after BT client disconnect: 175556
SPP_SERVER: Free heap after BT client disconnect: 175696
SPP_SERVER: Free heap after BT client connect: 175700
SPP_SERVER: Free heap after BT client disconnect: 175700
SPP_SERVER: Free heap after BT client connect: 175684
SPP_SERVER: Free heap after BT client disconnect: 175564
SPP_SERVER: Free heap after BT client disconnect: 175704

BlueDroid first run

MAIN: Free heap at start of app_main: 175716
MAIN: Free heap after BT setup: 144108
MAIN: Free heap after I2C setup: 141300
MAIN: Free heap after BT client connect: 142756
MAIN: Free heap after BT client disconnect: 143580
MAIN: Free heap after BT client connect: 142756
MAIN: Free heap after BT client disconnect: 143412
MAIN: Free heap after BT client connect: 142740
MAIN: Free heap after BT client disconnect: 141848

BlueDroid second run

MAIN: Free heap at start of app_main: 175716
MAIN: Free heap after BT setup: 144108
MAIN: Free heap after I2C setup: 141300
MAIN: Free heap after BT client connect: 142756
MAIN: Free heap after BT client disconnect: 131676
MAIN: Free heap after BT client connect: 142776
MAIN: Free heap after BT client disconnect: 134132
MAIN: Free heap after BT client connect: 142640
MAIN: Free heap after BT client disconnect: 133180

Looks like I have around 30k more free heap after initialization of the BT Serial when using BTstack. However, I think it will be difficult to use BTstack with Arduino-ESP32 because BTstack is

using their own app_main
injecting some header into the ESP-IDF sources
adding themself as component directly into ESP-IDF sources So if you want to use BTstack with Arduino-ESP32, you need a custom compiled ESP-IDF where BTstack is already injected.

copercini commented 6 years ago

@beegee-tokyo wow, awesome report!

I had thought in use BTstack for BTserial some months ago, even before BlueDroid support, but the commercial use requires a paid license, that is not compatible with this repo idea =( But it's good to know the differences for better futures projects, BTstack seems great

About the congest problem, as you are running everything on IDF, seems to be a problem that goes beyond Arduino Core, so there is more chance that you will have a solution opening an issue on IDF repo, because you can get some official Espressif support, including from who ported BlueDroid to ESP32

beegee-tokyo commented 6 years ago

@copercini will do this some time later. Right now I am too busy with 3 parallel customer projects for AVR Mega, ESP8266 and ESP32 (the one with the crazy Bluetooth requirements).

StuartsProjects commented 6 years ago

I was translating a LoRa GPS tracker program that runs quite happily on an 8Mhz Arduino Pro Mini across to the ESP32. The program sends formatted NMEA strings over Bluetooth to an Android mapping app that sees the Bluetooth as a local GPS.

On ESP32 it did notr work, I worked out eventually that the ESP32 was dropping parts (or all) of the NMEA strings. On doing some Goggling I found this issue and applied the suggestion above by @copercini to replace libbt.a, and indeed Bluetooth is now working as expected, so many thanks to @copercini.

I suspect I may be seeing something similar when parsing the incoming serial stream from the GPS, it appears to be dropping blocks of incoming characters (so the program does not report a GPS fix) is it possible a similar issue to this Bluetooth serial problem is also affecting the reading of incoming serial data ?

Ameritronik commented 6 years ago

@beegee-tokyo, Re: heap usage of BTstack, Hi beegee-tokyo, thank you for this heap report, excellent. I was wondering how you turned off the Bluetooth SPP in either case. Is there a "pause" and "restart" for either bluetooth libraries, so there would be no heap decrease? Anyway to keep the heap static, for bluetooth spp only?

Also, if possible , can you please share this test, I'd like to run it on my ESP32 to check for similar results. Thank you

beegee-tokyo commented 6 years ago

@Ameritronik Usually I am all in with open source and sharing. But this tests were done on a customer project and I cannot share the complete code. However, the code I used to test is based on BlueDroid/ESP-IDF and BTstack/ESP-IDF. I never really tested pause/restart functionality because after using Bluetooth Serial, we moved on to BLE Serial to reduce the power consumption. But even with using deep-sleep methods (10 sec measuring/sending - 20 sec deep-sleep) we didn't achieve the required battery lifetime and moved on to a different Bluetooth/BLE chip (Nordic).

copercini commented 5 years ago

Fixed! https://github.com/espressif/arduino-esp32/commit/96822d783f3ab6a56a69b227ba4d1a1a36c66268

This implements a kinda of software flow control that waits when get a ESP_SPP_CONG_EVT and transmits again when channel is free again, thanks @me-no-dev

demutech commented 5 years ago

In BluetoothSerial.cpp, ........ const char * _spp_server_name = "ESP32SPP";

define RX_QUEUE_SIZE 512

define TX_QUEUE_SIZE 32

........ It seems the limit of tx buffer is 32 bytes.

big-eng commented 1 year ago

I see @copercini said this was fixed a few years ago, but I am also experiencing a similar issue now when sending byte-by-byte data out over bluetooth serial at higher speeds (~250kb/s), using Arduino to program my ESP32. On the receiving end, there are missing bytes. I am struggling to even find the folder where the libbt.a is to apply the suggested fix. Any help would be appreciated!

EricHarbers commented 1 year ago

@big-eng: I encountered the same problem with higher speeds. The solution I made was to change the spp task priority in the BluetoothSerial.cpp file. This solved my problem. I changed the following lines in BluetoothSerial.cpp:

if(!_spp_task_handle){
    xTaskCreatePinnedToCore(_spp_tx_task, "spp_tx", 4096, NULL, ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY, &_spp_task_handle, 0);
    if(!_spp_task_handle){
        log_e("Network Event Task Start Failed!");
        return false;
    }
}

and in the front of the BluetoothSerial.cpp file:

ifndef ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY

define ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY (configMAX_PRIORITIES-1)

endif

and changed the queue sizes:

define RX_QUEUE_SIZE 512

define TX_QUEUE_SIZE 128

Attached my changed zipped [BluetoothSerial.zip](https://github.com/espressif/arduino-esp32/files/12802242/BluetoothSerial.zip BluetoothSerial.cpp file.

italocjs commented 9 months ago

@big-eng:

I encountered the same problem with higher speeds. The solution I made was to change the spp task priority in the BluetoothSerial.cpp file. This solved my problem. I changed the following lines in BluetoothSerial.cpp:
if(!_spp_task_handle){
    xTaskCreatePinnedToCore(_spp_tx_task, "spp_tx", 4096, NULL, ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY, &_spp_task_handle, 0);
    if(!_spp_task_handle){
        log_e("Network Event Task Start Failed!");
        return false;
    }
}
and in the front of the BluetoothSerial.cpp file:

ifndef ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY

define ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY (configMAX_PRIORITIES-1)

endif

and changed the queue sizes:

define RX_QUEUE_SIZE 512

define TX_QUEUE_SIZE 128

Attached my changed zipped [BluetoothSerial.zip](https://github.com/espressif/arduino-esp32/files/12802242/BluetoothSerial.zip BluetoothSerial.cpp file.

Hello, did it work for you? im still getting congested messages sending every 100ms (max size is 103 bytes per msg), the BT results is very poor.

[ 19340][E][BluetoothSerial.cpp:202] _spp_send_buffer(): SPP Write Congested!

EricHarbers commented 9 months ago

I 've reported this problem to Arduino, and they will use the solution in upcoming ESP32 Version 3.0.0. See also: https://github.com/espressif/arduino-esp32/pull/8859 So for me, this solution works fine. My BluetoothRead and BluetoothWrite functions are very small. In this functions, just copy the data blocks in one time, not byte by byte. See my code, which passes data between the Bluetooth and the SerialPort.

void bluetooth_receiveBT(const uint8_t *buffer, size_t size) { Serial.write(buffer, size); }

void bluetooth_receiveSerial() { size_t len;

while ((len = Serial.read(ReceiveBuffer, sizeof(ReceiveBuffer))) > 0) { SerialBT.write(ReceiveBuffer, len); } }

EricHarbers commented 9 months ago

@italocjs: Did you connect to the Bluetooth Service in master/slave mode? For ESP32 versions below 3.0.0 this also didn't connect very well. See: https://github.com/espressif/arduino-esp32/issues/8748 How do you connect to the Bluetooth? And where do you write your bluetooth data to?

EricHarbers commented 9 months ago

@big-eng:

I encountered the same problem with higher speeds. The solution I made was to change the spp task priority in the BluetoothSerial.cpp file. This solved my problem. I changed the following lines in BluetoothSerial.cpp:
if(!_spp_task_handle){
    xTaskCreatePinnedToCore(_spp_tx_task, "spp_tx", 4096, NULL, ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY, &_spp_task_handle, 0);
    if(!_spp_task_handle){
        log_e("Network Event Task Start Failed!");
        return false;
    }
}
and in the front of the BluetoothSerial.cpp file:

ifndef ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY

define ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY (configMAX_PRIORITIES-1)

endif

and changed the queue sizes:

define RX_QUEUE_SIZE 512

define TX_QUEUE_SIZE 128

Attached my changed zipped [BluetoothSerial.zip](https://github.com/espressif/arduino-esp32/files/12802242/BluetoothSerial.zip BluetoothSerial.cpp file.
Hello, did it work for you? im still getting congested messages sending every 100ms (max size is 103 bytes per msg), the BT results is very poor.

[ 19340][E][BluetoothSerial.cpp:202] _spp_send_buffer(): SPP Write Congested!

@italocjs: If you want to write more about this issue, please go to: https://github.com/espressif/arduino-esp32/pull/8859

italocjs commented 9 months ago

it seems that my issue was being caused by the serial terminal bluetooth app on android. i was testing with it and quickly got the buffer congested (even using 100ms delay between msgs), i have now created my own app and did not have any issues since. My issue was client side. I will try to investigate more and update that issue you mentioned when i have more information.

EricHarbers commented 9 months ago

Nice that you 've found the problem. I can use the Bluetooth channel at 300 kilo bit per second without any problem.

italocjs commented 8 months ago

Nice that you 've found the problem. I can use the Bluetooth channel at 300 kilo bit per second without any problem.

Wow, i'm not even close to 1kb! can you share an snippet of how you achieved this? Im sending log files over BT, 10 lines per second (each line with exactly 103 bytes)

EricHarbers commented 8 months ago

Nice that you 've found the problem. I can use the Bluetooth channel at 300 kilo bit per second without any problem.

Wow, i'm not even close to 1kb! can you share an snippet of how you achieved this? Im sending log files over BT, 10 lines per second (each line with exactly 103 bytes)

Attached some code snippets from my project. Hope you can understand them. snippet.zip

EricHarbers commented 8 months ago

I forgot the connect function:

void bluetooth_connect() { if (SerialBT.connect(bluetooth.remoteName)) { bluetooth.status |= BLUETOOTH_STATUS_CONNECTED; } else { bluetooth.status &= ~BLUETOOTH_STATUS_CONNECTED; } memcpy((void )&bluetooth.macAddress, (void )esp_bt_dev_get_address(), sizeof(bluetooth.macAddress)); }

italocjs commented 8 months ago

Thank you very much!!! i will study your code and implement it here!

espressif / arduino-esp32

BluetoothSerial silently drops bytes to be sent #1537

define RX_QUEUE_SIZE 512

define TX_QUEUE_SIZE 32

@big-eng: I encountered the same problem with higher speeds. The solution I made was to change the spp task priority in the BluetoothSerial.cpp file. This solved my problem. I changed the following lines in BluetoothSerial.cpp:

and in the front of the BluetoothSerial.cpp file:

ifndef ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY

define ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY (configMAX_PRIORITIES-1)

endif

and changed the queue sizes:

define RX_QUEUE_SIZE 512

define TX_QUEUE_SIZE 128

@big-eng:

and in the front of the BluetoothSerial.cpp file:

ifndef ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY

define ARDUINO_BLUETOOTH_EVENT_TASK_PRIORITY (configMAX_PRIORITIES-1)

endif

and changed the queue sizes: