Inconsistent Streaming Rates with Multiple BLE Devices on Windows
msanmaz opened this issue · comments
Description of the bug:
When streaming data from two identical Bluetooth Low Energy (BLE) devices on Windows, one of the peripherals consistently exhibits a slower polling rate compared to the other. This results in one device streaming data at the correct rate, while the other streams at approximately half the speed.
Expected Behavior: Both BLE peripherals should stream data at the same rate, ensuring consistent performance across devices.
Actual Behavior:
With a single device connected, the streaming operates smoothly at the expected rate.
The issue arises when the second device begins streaming. Upon activation of the second device's streaming, the streaming rate of the first device significantly reduces.
This leads to a scenario where one device streams at the correct rate, while the other's rate is halved.
Additional Context:
The initial setup and streaming with just the first device show no issues.
The problem is consistently reproducible and occurs only when the second device starts streaming.
Both devices are identical in hardware and configuration, suggesting the issue lies in the handling of multiple streams on the Windows platform.
I have followed the examples provided and made some adjustments, but I am uncertain if the issue originates from my modifications or if it is an inherent bug.
I'm having this tokio-console result that where I have discovered that pooling rate were too different..
Are you sure it's not the central radio experiencing some sort of saturation, depending on the amount of data being streamed?
I appreciate your suggestion about the possibility of the high data volume. To provide more context:
Each peripheral is streaming data at a rate of 250 samples per second.
Further Questions:
Based on this streaming rate, do you believe it is indeed likely that the central radio is reaching a saturation point?
If saturation is the issue, are there any recommended strategies or alternatives to mitigate this? For instance, could adjusting the sampling rate or implementing a different data handling approach on the central device help?
250hz samples, of what size, packed how?
BLE was not made for anywhere NEAR that kind of frequency. Remember you're packing into a send rate of like, probably 10hz-15hz on a good day with the wind blowing the right direction. So you're really sending ~25-30 samples at a time depending on the pairing of OS, radio, etc, and all of those samples are REQUIRED to reach the central device due to the guarantees of the protocol.
The Nintendo Joycon, which sends updates at 200hz on a 15ms packet timing, requires the use of... one of the much faster BT2/3 variants, can't remember exactly which. BLE is made for small bits of data showing up every so often, hence the "low energy" part.
Thank you for highlighting the limitations of BLE in handling high-frequency data streams.
To provide more specific details about my current setup:
- The data packets I’m sending are arrays of ASCII numbers, each packet being 232 characters in length.
- So we’re actually sending the data at a rate of 62.5Hz as each package contains four samples (250/4 = 62.5) from each peripheral
Given your explanation about BLE’s capabilities and the example of the Nintendo Joycon, it’s becoming clear that my current approach might be pushing the limits of what BLE is designed for.
Questions:
- Considering the packet size and the high sample rate, is it indeed likely that I am encountering limitations due to BLE’s design for lower frequency and smaller data sizes?
- Would it be advisable to explore Bluetooth 2/3 variants as a potential solution for this high data rate requirement?
- Are there any recommended practices for optimizing data transmission in this context? For example, reducing packet size or sample rate, or using a different transmission protocol altogether?
I’m looking for the best approach to achieve reliable high-frequency data transmission and would greatly appreciate your insights on possible adjustments or alternative solutions.
I don't have time to design your system for you, and that discussion is out of scope for this bug/repo anyways. We're here to support our code, you'll need to figure out the best transport for your project yourself.