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

BLE - GATT transmission rate limiting #37

Open
benjaminaigner opened this issue Jul 16, 2020 · 2 comments
Open

BLE - GATT transmission rate limiting #37

benjaminaigner opened this issue Jul 16, 2020 · 2 comments

Comments

@benjaminaigner
Copy link
Collaborator

On some phones (currently observed on one older Android device),
the received GATT HID reports are processed slower, which leads to noticeable delayed movements.

A possible solution would be a rate limitation for sending GATT data.

Open for discussion:

Relative data (mouse movements):

Should we discard received UART HID data if sent too fast
OR
should the ESP32 sum up mouse movement values & send them accumulated in one report?

Absolute data (mouse clicks & keyboard keys):

I think these should be sent ASAP (when the rate limiting timeout is finished), without further modification.

@ChrisVeigl what's your opinion?

@benjaminaigner
Copy link
Collaborator Author

Implemented both, behaviour can be changed via make menuconfig or idf.py menuconfig.
See: https://github.com/asterics/esp32_mouse_keyboard/tree/rateLimiter

@ChrisVeigl
Copy link
Contributor

Should we discard received UART HID data if sent too fast
OR
should the ESP32 sum up mouse movement values & send them accumulated in one report?

Absolute data (mouse clicks & keyboard keys):

I think these should be sent ASAP (when the rate limiting timeout is finished), without further modification.

wow - you were so fast implementing this i could not even add my comment ;-)
great that both options are available now!

i agree that keyboard reports and mouse clicks should not be discarded - but sending them ASAP could also lead to problems (e.g. a mouse clicks at a wrong position).
accumulations of relative data is IMO the best method and should be the default.

i added a PR with some comments: #39

maybe we can now remove the rate limiting which exists in the FlipMouse code:
https://github.com/asterics/FLipMouse/blob/56b854f2b889f4f2fac8f5503f65db2b070b8f90/FLipWare/bluetooth.cpp#L66

For this, we should integrate the rate limit settings of the ESP32 into the UART command protocol (to make it accessible from the host system / GUI).

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

No branches or pull requests

2 participants