Electrical – Quadrature Encoder Interface Circuit

You left out the all-important information about how fast the pulses will be coming in, so I'll just assume the worst cases pulses are still slow enough for properly written firmware to catch.

I have found a few tricks to doing quadrature decoding in firmware:

1. Don't try to catch individual changes, poll at regular intervals instead. Assume that the encoder can get stuck right on the transition for any one edge, and that edge can therefore rapidly dither. This would make a mess of any interrupt on change technique.

   With regular polling, you can tune the system carefully for how much time you want to spend in the interrupt routine. The upper limit of encoder speed is also nicely known, and isn't really any slower than the worst case with the interrupt on change method anyway. The polling method is guaranteed to work correctly up to some maximum motion speed you can easily calculate. The interrupt on change method degrades unpredictably as there is bouncing on transitions.

2. Always decode the full 4x position. Don't try to get cutesy and do stupid stuff like count +1 when A transitions while B is high, etc. These "shortcuts" are actually harder to implement and have corner cases that get you into trouble. Even if upper levels only want to know position to a single fully cycle, you keep yourself out of trouble by decoding the new position from every change of state.

3. Decode using a lookup table. Each interrupt, you take a snapshot of the current state of the two encoder lines. This together with the snapshot from the previous interrupt is 4 bits of data. From the previous state and the new state you can tell whether the 4x count stayed the same, or went up or down 1. Since there are only 16 possible cases, you can use these to dispatch from a table. There are 4 cases for each of staying the same, +1, and -1.

   There are also the 4 cases of the count having changed by 2 that require special handling. A change of 2 means that one transition was missed and the encoder is moving rapidly. From looking at the old and new state alone, you don't know whether it went forward 1/2 cycle or backward. Note that 1/2 cycle is a count of +2 or -2 in this system. The way I deal with this is to keep a last known direction flag. The code that does +1 and -1 sets this flag according to the known direction. When you get a step of 2, you assume it's going in the same direction as the last step of 1. That's a pretty good assumption considering inertia of real mechanical systems.

   In reality therefore you really have 5 bits of information to process each interrupt, the 2 previous encoder line levels, the new encoder line levels, and the last known direction. So for the ultimate in speed you make this a 32 entry table and handle each possible case with explicit code. The code for each of the cases adds from -2 to +2 to the current position and possibly updates the known direction flag.

As you can see, only a few instuctions are needed each polling interrupt. Your PIC (16F1825) can run at up to 32 MHz clock rate, which is 8 MHz instruction rate. Let's say you set up a interrupt every 50 instructions, which is well more than needed to do what I described above. That means you can poll at 160 kHz. Since the encoder can change by up to 1/2 cycle per interrupt, this supports up to 80 kHz encoder full cycle rate.

It sounds like a point-to-point system you are trying to "sniff" the data from and because of this you'd be well-advised to offer a high-impedance connection which can suffer a reasonable bit of common-mode voltage on the two lines relative to your "sniffer".

I don't know what data rate it's using but it'd be hard-pressed to task a MAX999 comparator.

I'd use 10k resistors from each line to the MAX999 inputs and I'd have 2 series 470R resistors across the MAX999 inputs to: -

1. Attenuate the signal
2. Act as a mid rail connection from your local sniffer power

The MAX999 will work down to very low input levels and attenuating most data transmission levels by ten is not going to be a big issue. The MAX999 also has a littel bit of inbuilt hysteresis too and works at 5V or 3V3 with a push-pull output that can directly feed micros and PLDs etc..