# 05-01 RSSI Collection memory leak

Using the ESP32 as the BLE Client side is blocking me from making progress. It is very frustrating to be hindered by system resource bottlenecks.

# Problem

Creating a new client the reconnect dynamically allocates memory in the heap. It is not destroyed in memory after disconnecting from the server and returning the RSSI value. After 74 connections, the BLE Client stops working. The BLEClient is blocking and thus locks up the program but the BLEClient stops in its track on create() when it realizes there is not enough heap left. The program freezes, but does not crash.

# Debugging output

First connection:

ITERATION COUNT: 0
currently connecting to server with address: 24:6f:28:7a:45:8e
creating a new client
24:6f:28:7a:45:8e
1
connection Count: 0
rssi
-57
Heap size (bytes):
61276

Last connection before freeze:

ITERATION COUNT: 77
currently connecting to server with address: 24:6f:28:7a:45:8e
creating a new client
24:6f:28:7a:45:8e
1
connection Count: 77
rssi
-56
Heap size (bytes):
5152

# Solution I already tried:

BLEClient::deinit() does not clear problem. It takes a boolean param releaseMemory that does clear all memory, but due to the way the BLE stack is built, it is impossible to reinitialize the BLE environment if releaseMemory is true.

# Solutions

# Delete Scanner

Source Save RAM by making sure to stop scanner and clear results after scan using

BLEDevice::getScan()->stop();
BLEDevice::getScan()->clearResults();

Source

# Create Tasks for FreeRTOS

Tasks are a way for FreeRTOS to manage system resourcs easily. Using tasks like in LynxyssCZ's sketch, it is possible to allocate resources for the Wifi and BLE stack to work on separate cores with separate heaps.

void setup() {
  Serial.begin(115200);
  BLEDevice::init("");
  WiFi.begin("ssid", "key");
  xTaskCreate(vTaskBleReader, "BLE_READER", 4096, NULL, 1, NULL); // here is the BLE stack
  xTaskCreate(vTaskWebServer, "WEB_SERVER", 4096, NULL, 1, NULL); // here is the Wifi stack
}

# Use free() instead of delete

In a github issue, a user shows that the free() statement helps with freeing up system resources.

# Switch to Raspberry PI

Instead of struggling on getting my code to run on the ESP32, I could just use an ESP32. There are multiple libraries to interface with BLE in similar ways to my C++ code. I did some googling and there seem to be more ways of accessing the BLE stack. The library "noble" https://github.com/noble/noble for instance has comparable features and runs on node.js which I already have some experience with.

https://github.com/nkolban/esp32-snippets/issues/786

https://github.com/espressif/arduino-esp32/issues/940

https://gist.github.com/chegewara/d3ed0e3365407f6d3abcffc486b2c462

# Conclusion

I am ditching the ESP32 as the client side BLE host device. Below are the main reasons why I have made this decision. I will spend most of today researching about portable alternatives to the ESP32 as a BLE Client that will let me focus on solving IPS related problems. I am running out of time on this project. I only have four weeks left and I am still trying to upload RSSI values to the backend. I have not even started to evaluate the RSSI.

# Reason 1: C++ is slowing me down

C++ has a very steep learning curve and prevents me from solving problems. Too much time squandered on learning about the language and figuring out how to coerce the code to work. I spend so much time fixing things that are not related to my BLE based indoor positioning system. Not only do I have to think about how to solve the algorithmical problems of an IPS, but I also have to think about how the code interacts with the CPU, stack and heap. I have to compile things separately and the Arduino IDE is very picky with how files are stored. Consider these examples of bottlenecking because of the build process:

# Days wasted because of C++ Software issues:

04-10 Create v.1 of Server: Spent 2 days trying to link code that was in a subfolder of the project. Still haven't figured it out.
04-14 Rewrite functions groups as classes: In hindsight I am pretty sure the build cache folder caused the compiler to link the previously compiled files. Changes therefore did not register

# Reason 2: The ESP32 is incredibly underpowered

My Desktop Computer I am writing this sentence on has 100'000 times more RAM than the ESP32. The difference is quite evident. The ESP32 has very limited hardware resources that I do not have the time to fix.

# Days wasted because of hardware issues:

04-13 App Storage Issues: The ESP32 had only 1.5 mB of free storage. My program was too large for this to handle it.
04-20 Uploading Measurements: HTTPS uses too much memory
04-21 Identifying Issue: figure out that my code is bad and memory is the issue
04-22 Try different fixes: try to fix it, but fail due to my inexperience
04-23 Async HTTPS: Async HTTP uses the same TCP stack that uses too much memory

# Reason 3: Espressif System's BLE library is bad for multiconnect

The loads that I am submitting to ESP32 are very expensive and are blocking me from making progress. Normal BLE operations are not very memory intensive, since they mostly involve a single connection and deal with reading some characteristics and notifiying clients. Multiconnection is very poorly supported in the main arduino esp32 core at the moment. There are a plethory of memory leak issues with the library. Here is a small sample of only the heap leak related github issue tabs I had open in my browser:

# Days wasted because of the BLE library

04-25 Refactor BLE Scan and HTTP: WificlientSecure uses too much memory
04-30 Multiple client handling: BT Stack only supports 3 Client simultaneous connection objects. Switch to single connections.
05-01 RSSI Collection memory leak

# 3D Prints

Today's 3D prints comprise of the version 2.0 and 2.1 of the server cases.

Case v 2.0 { width=75% }

V2.0 Issue: ESP32 does not fit in the holder, only fits upside down

Case v 2.1 { width=75% }

V2.1 Issue: Print quality is bad, buttons break off when removing support material

← 05-02 Noble and Nodejs 04-30 Multiple client handling →