The hardware to build a quadrature encoder is pretty simple. For the sensors, you need a couple of photo-interrupters and something to do some very lightweight logic and timing calculations (in my case the Arduino). The encoder is a slotted disk, with equal length and spacing of “light” and “dark”, which rotates through the slot of the photo-interrupters (I will post the circuit that I used in a follow-up). The photo-interrupters need to be spaced at a quarter of a wavelength (1 wavelength = the total length of one light and dark section of the slotted disk.)

For my proof of concept, I bread-boarded the components and used a piece of card, cut to mimic the slotted disk.

High-Tech Encoder Simulator

Spaghetti

The Logic

Below is a table and sequential images showing the sensor outputs. Note that the reference sensor is the left one. (The phase number printed on the card when aligned with this sensor corresponds to the phase in the table.)

Phase	Sensor A	Sensor B	Image
1	0	0
2	0	1
3	1	1
4	1	0
1	0	0
2	0	1
etc…	etc…	etc…	*Mongkut

By only looking at the outputs each time Sensor A changes state, we can tell which direction the encoder is travelling.

If we step through the table rows above, when the state of Sensor A changes from 0 to 1 (phase 2 –> 3), the sensor values are both 1. When Sensor A changes from 1 to 0 (phase 4 –> 1), the values are 0 and 0.

Forward Direction

If we now go from bottom to top. When the state of Sensor A changes from 0 to 1 (phase 1 –> 4), the sensor values are 1 and 0. When the state of Sensor A changes from 1 to 0 (phase 3 –> 2), the sensor values are 0 and 1.

Reverse Direction

In simpler terms: when Sensor A is triggered, if both of the sensor outputs are the same, our encoder is travelling forward; if the sensor outputs are different, the encoder is travelling in the reverse direction.

Give or take a negation, this is the exact behaviour of the exclusive disjunction (or exclusive or ; “XOR”) logical connective.

Restructured to look more similar to my sensor output table:

So, this very long-winded look at the sensor outputs and comparison to the “XOR” logic table gives us the following pseudo-code:

When Sensor A changes

if Sensor A XOR Sensor B then

direction = reverse

else

direction = forward

All that’s left to do is to time how long between interrupts on Sensor A; count the number of notches on your disk and calculate RPM to give you the shaft speed. Easy!

I will do another post shortly with the Arduino specifics and code. (TODO: insert link here)

NB: The forward and reverse directions of the encoder, the reference sensor and the logical states represented in each phase are entirely arbitrary. I am sure many examples will have made different assumptions around these conditions and will therefore show variations of the output tables etc. The concepts remain the same, it’s just the detail that changes.