Hi Arden, On Thu, 29 Jun 2023 at 02:32, Arden Kolodner <akolodne...@amherst.edu> wrote:
> Hello! I’m having an issue with NimBLE (but not any other BLE stack) on my > ESP32-S3 device. I submitted an issue on GitHub but didn’t hear anything > back, and I just found out about this email, so I thought I’d ask here too > in case someone has seen anything like this before. > > I have an ESP32S3 connecting via BLE to multiple MbientLab MetaMotionS < > https://mbientlab.com/metamotions/> devices. The BLE client on the ESP32 > subscribes to a characteristic on each device, which is supposed to send a > notification update at 100Hz. This works fine when using Bluedroid, but > unfortunately Bluedroid causes other problems down the line and we want to > switch to NimBLE. > > However, for some reason, when using NimBLE, most of the notifications > from all devices except the last one are dropped. Each time a new device is > connected, the device that was previously the most recent connection > suddenly develops this problem, in addition to all previous ones. Only > about 10% of the notifications go through, which is far too few for our use > case. > > We found that lowering the min and max connection interval made more of > the notifications go through, but still not most, even when trying the max > value. > > Oddly enough, setting the connection parameters will reverse the issue: > the first connected device will now be the fast one, and the others, > including the last one, will be slow. This seems to be the case even if I > set the connection interval to a very large value, instead of very small, > and even happened sometimes when I set invalid connection parameters and > got an 0x0212 HCI error. So maybe it’s not the actual parameter values that > are affecting anything, but some side effect? > > Since the issue doesn't occur with Bluedroid, and nothing else is changed, > the problem seems like it must be with NimBLE. > > Does anybody know why this problem occurs or how to fix it? > If there's anything wrong with the host stack it's likely the controller that triggers it since I cannot see why changing connection parameters would affect connection handling in the host stack. The best would be to have capture from a BLE sniffer so we can take a look at what's happening over the air. If not possible, then at least HCI logs from central side (i.e. ESP, I assume) in some easily readable format like btsnoop. Also corresponding logs from Bluedroid would also be nice to compare. > Note: we use NimBLE through the esp-nimble-cpp library, but this seems > unlikely to be the issue since it just provides an interface for BLE > connection and callbacks just immediately call our code. > > Thank you very much for your time. BR, Andrzej
