[Rickertsen2]

Originally Posted by Mark McLeod

It's not an issue if you're counting many revolutions in one direction just to get a distance or counting the RPMs of a shooter wheel for velocity control, but for an application like pan where it mostly hovers in one position and is not turning your encoders at a steady rate very far in any one direction, it'll bite you.

The answer is simple enough as you think about what's happening. Here's an explanation for those anonymous readers who haven't caught on to the dynamics of what's going on.
The A-line goes high and you count it, because you know the direction for certain. It rolls back and the A-line goes low, but the code is written to ignore that transition. Not a problem if the encoder continued to move back and hit the last rise of the A-line. It's only an issue when the encoder is poised right at the cusp of the transition from high to low. For instance, think about what happens if just general robot vibration causes the encoder to oscillate just a tiny bit back and forth over that transition point. If the line goes high, then back drives low (so to speak) and goes forward again it looks the same interrupt-wise as constant motion forward.

For this type of application no transition of the A line, high or low, can be safely ignored. Each transition of A must be enabled for both directions, going high at one spot and going low at that very same spot. Everywhere the code can add a count it also must be written to subtract a count, allowing for any backward motion of the A line as well as any forward motion at any single transistion point.

I imagine Kevin's encoder code to handle this issue must test and count both high and low transitions.

Thanks. I will rewrite my code to use the port B interrupt on change and count rising AND falling edges if i get to the regional and see that this is the cause of the issue. I didn't do this initially because i overlooked this problem and thought that both edges would just eat more processing time.