Subscribing to a characteristic?

[FugLong]

Hi, I'm integrating ble_serial with an arduino 33 ble based head tracker for pc games (using opentrack and its hatire plugin).

Basically I'm just having trouble getting the central (ble_serial) to update fast enough to pass head tracking data to opentrack effectively. It works, but is clearly updating only once every half second or so. I understand BLE is really not meant for constant communication but I have learned about BLE characteristic subscription and think it may be what I need.

I have the notify flag set on my read characteristic but I can't figure out how to get ble_serial to subscribe and listen to those notifications. Is there a way to enable subscription? Monitoring on my phone it seems pretty responsive but it's hard to tell with raw numbers.

I'm generating and sending 30 bytes at around 100hz in usb mode and attempting the same over BLE. Is this a pipe dream or is something like this possible?

*Edit: Looked into the bluetooth chip on my arduino (u-blox NINA-B306) and it should support way more than this throughput with no issues according to the data sheet. Also think descriptors might be the issue? The characteristic has a notify but it also has a "Client Characteristic Configuration" descriptor (UUID: 0x2902) that says "Notifications or indications disabled". Can't figure out how to modify that with ArduinoBle library.

*Edit 2: I've learned more about Cccd and I modified the Arduino BLE library to set the Cccd of my characteristic to 0x0001 (Notifications enabled) and it does seem to be updating faster, but it's still either losing 50% of its packets or updating too slow. Not sure how to diagnose, I'm new to bt. Still acting like it's only updating every 250 ms or so.

[Jakeler]

Hi @FugLong,
so purely from a bandwidth perspective it should be possible. 30B*8*100 = 24 kbit/s, which is a slightly above with the 21 kbit/s I was able to achieve in testing: https://blog.ja-ke.tech/2021/04/22/ble-serial-2.html#performance
That is not too far off and should be doabale with some tuning. What if you start with 15/30/60 Hz at first, does this reduce the packet loss?
Otherwise it might be buffering on your Arduino? So that it waits for the buffer to fill up and then sends a large burst, which overwhelms the ble stack and increases the latency. See also: #59 (comment)

About subscribing: ble-serial should automatically try to write the CCCD for notifications via start_notify in bleak, but seems like you already solved this in the peripheral Arduino code.

For debugging the PC side try ble-serial with -v to check if the data comes in fast enough (maybe plot the timestamps) or if the problem is somewhere down the line with serial writing+reading and opentrack.

[FugLong]

Thanks for the insight! Very glad to hear you achieved 21kbit/s, I was getting doubtful about BLE's ability. The 100hz output of the arduino is just a default and nothing relies on that specific rate so I should be able to decrease it quite a bit before I see performance loss. I will do some testing and logging today and let you know how it goes.

[FugLong]

After further testing I've found that decreasing the frequency of the arduino loop did not help, and it degraded performance much more than I thought it would. Honestly I might try to separate the angle measurement and data sending loops in my code to ensure the slow speed isn't affecting IMU readings. I also got notifications working without modifying the arduino ble srouce code (silly mistake on my end).

I did more testing at around 99hz with the ble_serial verbose flag set and that is really where things got interesting. The latency and performance were actually not that bad, but there is some sort of buffer induced stuttering going on I think.

There was a pretty consistent trend in how the data was coming in. Ble_serial receives three packets extremely close together, some even at the exact same time in the log, none more than 0.003 away. Then after a cluster of 3, there is a 0.050-0.080 delay before another cluster. Sometimes 4 make it through before the delay but it's almost always 3.

I may be doing something wrong in terms of packet size. The opentrack plugin expects packets of 30 so that's what I'm trying to send but I'm starting to think it's not quite working as I want it to. Maybe it's only sending in packets of 20 or 27? I know there is a way to extend the size but I do not know how. I will verify these speculations tomorrow.