Reading/Polling Buffer
See original GitHub issueHey, it’s me again 😄 I hope I’m not bugging you by now 😉 But I’d really need your advice again 😕
So here’s the thing:
I’m packaging uint8 (sbyte) packages on my ESP32 and sending them as 1 byte packets over my characteristic:
uint8_t package[1]; package[0] = convertRawAngleToDegrees(ams5600.getRawAngle()); pCharacteristicCommand->setValue(package, 1); pCharacteristicCommand->notify();
It does nothing but continiously sending out a current HALL sensor angle value over BLE.
Then in Unity I have a Thread thats reading the buffer like you showed in your example “ReadPackage()” function:
Impl.BLEData packageReceived; bool result = Impl.PollData(out packageReceived, true);
First I couldn’t figure out how to access the data without HUGE latency (half a minute or so), until I made a really unpretty workaround:
On my ESP32 I created a full package with 512 one byte packages before sending it out. With this “throwing s*** on the wall until it sticks approach” I could access my values from Unity 😉
This was fine for debugging, but using the data for a game/simulation input is far too slow 😕
On the UWP platform one could use the DataReader Interface I guess? Do I have a similar option with your DLL? I have also an Android app where I can receive the same data perfectly with a BLE characteristic “Notify”. I have tried it in block and non block mode btw, but I’m not sure wether I used it correctly.
Long story short: How can I read the LATEST momentary value sent out from my BLE device at any given time?
Like I said, I’m sorry to have to bother you again, but I have tried for several hours 😭
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
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!
Or you can try out writing packages to your ESP in a regular interval (<30s, e.g. 2s).