BLE: rate limiter / commands to addon module in general

[benjaminaigner]

For adapting the rate limiter, a new AT command needs to be implemented.

But in general, I would prefer to use a general AT command, which is used to send arbitrary commands to an addon board.

Suggestion: AT BC <command (according to asterics/esp32_mouse_keyboard#39
e.g., AT BC $RL80 sets the rate limiter of the esp32 addon to 80ms.

In general, these commands can/should be:

• sent from the GUI
• sent from a WebGUI
• stored in the EEPROM (we should agree on a procedure how an array of external commands can be saved in EEPROM).

[klues]

What is the BLE rate limiter and in which cases it has to be adapted?

[benjaminaigner]

In general, there is a maximum sending frequency, because of the underlying protocol limitations.
In case of the FLipmouse, there are 2 limits, depending on the used HID interface (Bluetooth or USB):

USB:
USB-HID data is transferred by an endpoint in interrupt transfer mode.
This results in repeating polling by the host, in an interval which is defined in the USB descriptor.
The minimum interval is 1ms, so max. 1000 HID reports each second.

The limit is handled by the USB hardware integrated in the Teensy uC, so each time we call Mouse.move()
we trust on the Mouse library to handle any buffering and data transfer. So no rate limit there, except a general "tick time" for the main loop.

Bluetooth:
Bluetooth data is sent a little more complicated:

• Serial interface to any BT board (the first attempt was an EZ-Key HID module on a breadboard, currently we use a
  custom ESP32 PCB with our firmware) in 9600Baud. So we need to consider this interface in any timing and buffering.
• ESP32 handles via GAP & GATT events the connection to any paired device.
  (there is another issue there on how pairing is handled for the user).
• ESP32 buffers the HID data and sends it via a GATT notification to the BT host (central device)

We experienced problems with some devices, which could not handle a high data rate very well (BT).
The mouse moved with a noticeable delay in the movements (~500-1000ms), which renders the FM nearly unusable.
To overcome this issue, we limited the BT sending in the FM by a timestamp based limitation and we discard any packages which are sent more often.
For a rate limit which is a long time (e.g. 50-200ms) we loose many fine steps of mouse movement.
A short time between HID data transmission might result in delays on some BT devices, but gives a precise mouse control and most of the devices.

So: we need a good default value and the possibility to adapt this value if necessary 👍

Because the BT rate limiting (and an additional buffering specialized on mouse data) is implemented in the ESP32,
we could introduce a general AT command which can send data to the BT addon.
There are a few more use cases for this:

• Enable/disable pairing mode in BT
• Enable/disable the WebGUI on the FLipMouse
• Fetch all paired devices
• Delete on existing pairing
  (and maybe more)

[klues]

Thanks for the detailed explanation! 👍

This results in repeating polling by the host, in an interval which is defined in the USB descriptor.

Crazy, normally one would think a mouse would be the perfect device to trigger events if something happens and not using polling by the host.

So: we need a good default value and the possibility to adapt this value if necessary 👍

OK, makes sense!

Do you know how other Bluetooth mouses deal with this problem? Do they simply have a good default value?!