David Buezas

I see. I didn't think of that. > But as soon as you move two encoder dents in either direction, the bug disappears It should disappear as soon as the...

Exactly! You can also reduce the resting time to 250ms, if that's perfect already maybe we don't need to re-add the old (more complicated) code.

Ok, then we're getting somewhere:) I'll spend some time looking at the old logic and the new one and push some new code this week. > Is there perhaps some...

I tried the old reset algorithm and it makes my encoder (2 pulses per step) feel all mushy. If I move the wheel one step at normal speeds, it will...

All right @XDA-Bam. I re-added the old logic. The difference is that a reset may result in a full step movement if encoderDiff is past half a step (i.e ±3...

> Overall, this makes the encoder much less predictable than occasionally "forgetting" a step in my opinion I strongly agree > If these suggested changes are implemented, I would say...

There's one (last?) trick we could try: only apply the threshold rule is the direction has changed

Ok, @XDA-Bam, I added the last test. It "_advances the encoder after a while if it has crossed the half a step threshold while changing direction_" There's now two timeouts...

Sounds good. I'll be happy to see that nasty hack go

After ~2 months of use, I haven't noted any issues with this, and the LCD is extremely snappy. Please let me know if there is anything pending on my side...