Scroll Wheel Can Spin Faster than the Sensors Can Detect

[IBNobody]

Because the scroll wheel does not have a clicking mechanism similar to other mice/trackballs, the wheel can spin and coast freely. This feels fine from an ergonomic standpoint, but I noticed issues with the scroll wheel sensor.

When I spin and coast the wheel, the IR LED / phototransistor combo first detect that the wheel is spinning in the opposite direction. It then stops scrolling, and finally it begins scrolling in the correct direction.

Probably a similar effect to this... https://www.youtube.com/watch?v=VNftf5qLpiA

I suspect this is due to whatever sampling rate QMK was set up to sample the phototransistors. I saw that the code has a debounce time of 5ms, which (if the sampling rate of the wheel is handled by a counter) would be about 200Hz. Could this be dropped to 2 or 3?

[kevinlekiller]

Noticing this as well, figured it was because of the small pieces of filament wire I couldn't get rid of inside the encoder, but your theory makes more sense.

[mfish38]

Looking at the QMK source code, I believe that this is due to debounce logic on the scroll wheel. It looks like by default scroll events are ignored if they occur within 5 ms of a previous event.

I tried reducing the debounce time and it seemed to improve the issue without introducing any issues. To do this in your QMK keymap folder create a "config.h" if does not exist and add:

#define OPT_DEBOUNCE 1  // (ms)

You can try 0 to disable the debounce completely, but I suspect that this might cause issues if there is any noise.