[Bug]: Double tap as button press unreliable

[tropho23]

Category

Other

Hardware

Rak4631

Firmware Version

2.2.15

Description

Using the 'double tap as buttons press' is unreliable. Response to my taps vary randomly among delayed, ignored, or interpreted as four taps (screen scroll twice, or more). It seems unusable for me, at the moment. I have reproduced this issue on both a RAK19007/4631+RAK1904 and RAK19003/4631+RAK1904. RAK1904 is the 3-axis accelerometer sensor module.

If I shake the device side-to-side, rather than tapping it works slightly better but it's not predictable; the device might recognize the shake and it might not, or it thinks I've tapped/shaken twice. I'm not sure if the motion sensing is buffering and producing a delayed action or if the movement threshold is too high or low.

Also perhaps a cool-down period of perhaps 1-2 seconds between tap/shake responses could be added so the user can confirm the screen has advanced and doesn't start wildly tapping/shaking the device if it seems unresponsive.

I really like the idea of this feature and think it would be especially useful for a RAK19003 since this board lacks an easy way to add a user button (otherwise requires a custom mini IO sensor board or microsoldering directly to the appropriate 4630 package pin for IO5).

Relevant log output

No response

[thebentern]

Updated thoughts... We should take a cue from the recent change to interrupts for user buttons. This sensor has interrupt pins that we can use in that sense instead of polling.

[polamnus]

I ran into a similar issue after installing a momentary button between AIN1 and GRND. It's hard to accurately achieve the multi-clicks. About half the time, clicks will be interpreted as two subsequent single clicks instead of a single double-click.

Correct me if I'm wrong about this, but if I'm interpreting this correctly, a "click" is a press between 1-250ms in length ,based on this code: https://github.com/meshtastic/firmware/blob/0afe2d459fb1d9bfc8357a25b76da7b6b53a1ff1/src/ButtonThread.cpp#L53C1-L64C7

Might it be advantageous to expose that 250ms threshold as a user-variable?

I think in my case, my buttons are 8mm analog momentary buttons...not surface mount, so could do with a longer threshold. I'm wondering if the accelerometer's input is likewise being read outside the tolerance of that 250ms threshold. I'd love to be able to adjust that to see if I can't get more reliable multi-clicks.

It gets tougher once you realize triple and quad-clicks are a thing for GPS power toggle and e-Ink refresh, respectively.

Glad to help test anything that might be helpful or useful!