Reading/Polling Buffer about blewinrtdll

[adabru]

Using the BLE characteristic "Notify" seems right to me.

I'm not sure what may be the cause in your description. One thing you could try out is changing your bluetooth dongle. For my project I tried 3 different ones until the last one had the performance I'd expect from BLE. But I doubt that is the reason here.

The timespan of half a minute reminds me of another thing. I am also using an ESP32. The BLE-connection (scan + Connect()) normally takes less than a second. Also the subscription to the characteristic notify event is normally very fast. The data is sent with latencies around <10-50ms, I didn't measure more exactly yet. After subscription the ESP32 starts sending its packages. Now, if I restart the program and it tries to reconnect, I have to wait somewhere between 30-60s before it connects again. I found out that the ESP is sending out packages around 60s after subscrption. Then it will stop sending them if it didn't receive any response from Windows. I guess it will think the connection was lost. If I send any BLE package from Windows to the ESP the 60s-timer is reset. I am not sure why Windows can't connect to the ESP while it is sending its package-stream. My guess was data-congestion on ESP-side. In my case I added code to the ESP that reduces the timer to 1s, so that reconnection is faster.

Another problem I had was when I sent data from the ESP too fast. I guess that was also due to data congestion, probably on ESP side but could also be on dongle or Windows side. Enforcing a maximum packages per second rate should avoid that. That could explain why it starts working when your ESP waits 512 sensor readings before it sends a package.

[adabru]

Or you can try out writing packages to your ESP in a regular interval (<30s, e.g. 2s).

[Joelx]

Thanks again for the help. You definitely brought be on the right track here again :)
I looked a bit closer inside your BleWinrtDll.cpp and it seems that you are actually using the Notification for characteristics subscription:

fire_and_forget SubscribeCharacteristicAsync(wchar_t* deviceId, wchar_t* serviceId, wchar_t* characteristicId, bool* result) {
....
....
auto status = co_await characteristic.WriteClientCharacteristicConfigurationDescriptorAsync(GattClientCharacteristicConfigurationDescriptorValue::Notify);

So accessing
Impl.PollData(out packageReceived, true);
packageReceived.buf[0]
should be sufficient for reading a byte from the characteristic. I was a bit on the wrong track in thinking that the problem was on my processing on the Unity side.

Turns out, the keyword for my problem is, like you mentioned, "data congestion". After reading your reply I tried one simple thing.
On my ESP32 program, after sending my packet, I added a simple delay(50):
pCharacteristicCommand->setValue(package, 1);
pCharacteristicCommand->notify();
delay(50);

.. and this ACTUALLY seems to have done the trick. It's not that I hadn't thought about it, but idk like I said - I was a bit on the wrong track :)
I will have to fiddle around with and tweak it a bit, but overall I think that may have solved my problem!

[sbExperiential]

@adabru Do you remember the dongle that you used?

[adabru]

@adabru Do you remember the dongle that you used?

Sorry, I don't ☹. It was provided in the office.