Encoders, interrupts, and edge-triggering issues

[Alan Anderson]

I just fixed a nagging problem with our encoders tonight. The nature of the problem is such that I think many people might be suffering from it. Here's the deal:

The encoder counts wouldn't always track the motion properly. Theoretically, for one full rotation, the software should always see exactly 64 counts. On occasion, it would apparently miss counts. Even though I was sure the rate wasn't too high, I added the 7474 "Phase B Catcher" circuit. I don't know whether or not that fixed the original problem, or if I was misunderstanding what was wrong in the first place, but a new and consistent problem appeared: it would often give extra counts.

Analyzing the situation yielded a theory. If the encoder were at a point where a little bit of wiggling made the Phase A signal change, it would get an interrupt for each wiggle past that point in one particular direction, because the interrupt is configured to occur only for one edge. That theory was supported by intentionally wiggling the encoder back and forth repeatedly until it started counting with no net motion actually occurring.

To fix it, I added code to toggle the interrupt edge from rising to falling, and vice versa, each time an interrupt occurred, and to treat the Phase B signal backwards for the additional edge. Now it interrupts (and counts) twice as fast, but it never loses a count or sees an extra one.

And the 7474 circuit apparently isn't necessary -- saving almost a half ounce of weight.