[Alan Anderson]

Originally Posted by Kevin Watson

If I remember correctly, several months ago Alan mentioned that he had a problem using this scheme in his position control application because his mechanism would sometimes stop right on a tick mark and generate a bunch of spurious interrupts, which would cause problems because the phase-b signal might change before the ISR could read it.

That's not quite how the problem manifested itself. The B phase isn't going to be changing at all when the encoder is hovering at an A phase transition, so the time it takes to read it isn't really an issue. The actual problem is that this simple scheme only notices the 0->1 transition, and ignores the 1->0 transition that accompanies a miniscule reverse motion of the encoder. Instead of recognizing that the encoder is "vibrating" at one spot, the software ends up counting things as if the encoder were continuously moving in one direction. Our solution was to set the hardware to interrupt on both the rising and falling edges, and complicate the interrupt service routine accordingly to recognize all four possibilities instead of just two. (That was difficult because our position tracking system used three encoders, and the RC only has two digital inputs capable of being configured to interrupt on both edges.)