Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Polling Rate in Dual Bluetooth Low Energy (BLE) Device Streaming on Windows (.NET Framework) #393

Open
msanmaz opened this issue Jan 31, 2024 · 0 comments
Labels

Comments

@msanmaz
Copy link

msanmaz commented Jan 31, 2024

Description
Issue

When streaming data from two identical Bluetooth Low Energy (BLE) devices on Windows, one peripheral consistently streams at a slower polling rate than the other. This discrepancy results in asynchronous data streaming rates between the devices.

Expected Behavior
Both BLE devices should stream data at an equal rate, ensuring consistent and uniform performance.

Actual Behavior

Single Device Connection: Smooth data streaming at the expected rate.

Dual Device Connection: Upon activating the second device's streaming, the first device's streaming rate significantly reduces, leading to asynchronous rates (one at the correct rate, the other approximately half).

Additional Context

Setup with One Device: No issues observed.

Issue Reproducibility: Occurs only when the second device starts streaming.

Device Similarity: Identical hardware and configuration, suggesting the issue might lie in handling multiple BLE streams on Windows.

Initial Development Environment: Initially encountered in Rust, the issue persists in .NET with InTheHand.Bluetooth.

Mobile Development Comparison: In SwiftUI for mobile, both peripherals stream without issues. However, macOS streaming slowed down post-Sonoma update. Windows streaming has always exhibited slower rates for the first connected device.

Observations

Unresolved Problem: Despite following examples and making adjustments, the issue remains, raising questions about whether it's a systemic bug or an implementation error.

Success in Mobile Streaming: Successful streaming in a SwiftUI mobile environment contrasts with Windows issues.

Streaming Rate: Data is sent at 62.5Hz, with each package containing four samples from each peripheral (250/4 = 62.5).

Request for Assistance
I'm uncertain if this is a general bug in how Windows handles Bluetooth streaming or if it's an error on my end. Notably, I'm using CharacteristicValueChanged to listening the notifications in my implementation. Any insights, suggestions, or similar experiences would be greatly appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants