I've got a board with four rotary encoders on it. Two of them work well, but the other two would occasionally jump positive by counts of ~8-16 while being turned in the negative/CCW direction, with the result that progress could not be made turning them CCW. This occurred no matter how fast or slow I turned the encoders.
Delving into the Encoder library code, I saw that transitions 3, 6, 9, and 12, normally considered invalid, were being counted as +/- 2. I commented out those counts and the problem cleared up entirely.
I'm guessing that (a) my un-debounced hardware is occasionally presenting invalid data, and (b) the +/- 2 counts are there to support fast-moving encoders that the Teensy isn't quite able to keep up with.
I almost reported this as an issue on the github repo but accepted the issue form's strong encouragement to come here.
This seems like a borderline bug. The +/- 2 counts clearly have value to some use cases, but they can ruin the functionality of the library in a basic use case. One solution would be to make the +/- 2 count an optional feature that has to be explicitly enabled. Another helpful feature would be to show a typical debouncing schematic on the Encoder page -- the protoboard photos show the necessary resistors and caps, but they aren't explained.
In any case, I have a workaround for the moment and will add hardware debounce in my next rev.
Delving into the Encoder library code, I saw that transitions 3, 6, 9, and 12, normally considered invalid, were being counted as +/- 2. I commented out those counts and the problem cleared up entirely.
I'm guessing that (a) my un-debounced hardware is occasionally presenting invalid data, and (b) the +/- 2 counts are there to support fast-moving encoders that the Teensy isn't quite able to keep up with.
I almost reported this as an issue on the github repo but accepted the issue form's strong encouragement to come here.
This seems like a borderline bug. The +/- 2 counts clearly have value to some use cases, but they can ruin the functionality of the library in a basic use case. One solution would be to make the +/- 2 count an optional feature that has to be explicitly enabled. Another helpful feature would be to show a typical debouncing schematic on the Encoder page -- the protoboard photos show the necessary resistors and caps, but they aren't explained.
In any case, I have a workaround for the moment and will add hardware debounce in my next rev.