ArdenKolodner
commented
1 year ago 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?
I have an ESP32S3 connecting via BLE to multiple MbientLab 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 changing the connection interval with setConnectionParameters made more of the notifications go through, but still not most, even when trying the max value.
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?
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.