You are reading a single comment by @Franzo and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Franzo
@Sebastian: I also agree on the lost "release" packet theory: a repeated keystroke can almost always stopped pressing the corresponding button again.
Regarding the operating distance, I generally use HID and experience this issue when I am at least 2 m from my PC. Only when I stay at a "safe" distance (< 0.5 m) during the whole duration of hidkbd app operation the issue seems not to be happening.
As already mentioned in my first post, I am pretty sure that the problem lies in the Bluetooth reconnection procedure. If I force a disconnection and wait for reconnection, I can reproduce the bug even at a safe distance. Probably the increase in keystroke misses and repeats rate that you experience during long range operation is the consequence of a reconnection triggered after a momentary lost signal disconnection.
@Gordon: in my use case (media playback control) the 'key stuck on' problem is much more harmful than the missed key. So yes, I would be very grateful even only for a fix for the repeated keystrokes problem!
So, if I got this right from your post, in the BLE HID protocol a sort of ACK is expected after each keystroke. If this is true, maybe even the missing initial keypress could wait until a timeout and report a failure as an exception of
kb.tap()call. This exception could be caught from user code such as hidkbd and possibly trigger anotherkb.tap()call or print an error message on screen. This, combined with my reconnection routine described in post #9, should do the trick!What do you think? Can this be feasible?