Debouncing rotary encoder circuits

[shushi_boi]

Hi,
In this Raspberry Pipboy Project,


Niel Corbett attempted to recreate the pip boy as a real life functional device, and in this project he is using two rotary encoders.

Here' the link to the code for his project,
https://bitbucket.org/selectnone/ra...ls.ino?at=master&fileviewer=file-view-default

and the micro controller that he is using for this project is the Teensy++ 2 [uses 5V for its pins] which is connected to the Raspberry Pi (although currently he decided to just us the Raspberry Pi GPIO i/o pins directly instead).

So, I was interested in taking the circuitry for the rotary encoders a step further and I'm trying to debounce the circuit.
Generally this is how one wires an encoder's circuit in order to debounce it;
+5V > Resistor > Encoder + Teensy > Capacitor > Ground

Based off of that, I drew this schematics on how I believe this circuit should look.

For the Resistor, I am using a 10K Ohm 1/2 Resistor, and between the capacitor and the encoder, I am using an 1N4001 Diode
http://www.engineersgarage.com/electronic-components/1n4001-diode

Based on how I have the circuit set up, does this circuit appear to work?

Also, about the polarized capacitor that I am using, I'm not too sure on what specific ratings to look for on capacitors for this project as I hardly ever deal with them as a hobbyist. In order to find a capacitor that will make the rise time slow enough so as to filter out switch bounce but also fast enough to allow the encoder to work fast enough, what kind of ratings should I look for in a capacitor for this project?

Thank you for your time, and I apologize for asking, I'm barely new to electronics and I have a passion to learn about them :)

 

[Svein]

I have used software debouncing in a couple of projects. It goes somewhat like this:

• Set up a timer to generate clock interrupts each millisecond or so
• Assign one buffer byte and a "debounced value" byte to each input
  
• Decide on a "debouncing constant" (how many reads should be equal before you accept the input value). A value of 5 is usually OK.
  
• At each interrupt, shift the buffer bytes left and insert the value of the corresponding input into the LSB
• Whenever the "debouncing constant" number of bits agree in the buffer bytes (all 1's or all 0's), update the "debounced value" byte

 

[Baluncore]

Firstly; as an A–B output encoder is rotated it generates two approximate square waves that are phase shifted by about 90° like sine and cosine. Any noise due to sitting on the edge of a transition will simply jump backwards and forwards between two adjacent states.
Secondly; any contact noise in an A–B encoder, on either the A or the B contact will do the same as above.
Contact noise on two outputs would suggest you should replace the encoder.

If you are polling the A–B signals, then noise could waste some processor time handling irrelevant transitions.
If you use interrupts to detect changed A–B state, then the processor could run out of time handling noise.

The software de-bounce solution is counter-intuitive and avoids time constants.
It works by updating virtual copies of the A and B status in an internal register.
When the external A signal changes state, read the status of signal B and copy that to the virtual B register.
When the external B signal changes state, read the status of signal A and copy that to the virtual A register.

Repetition of edge oscillation or contact transition bounce will then make no change to the internal virtual registers.
The processor need only change the position count register when an internal virtual A or B register changes.
There will be a maximum delay of one quarter of a cycle in the encoder position appearing in the virtual register.

I have done the same thing externally in hardware by using 'D' flip-flops and XOR gates to clean up a signal.

 

[Svein]

Firstly; as an A–B output encoder is rotated it generates two approximate square waves that are phase shifted by about 90° like sine and cosine. Any noise due to sitting on the edge of a transition will simply jump backwards and forwards between two adjacent states.

It depends on the type of encoder. The quadrature encoder (which you are discussing) is not very sensitive to contact bounce, but an absolute encoder may get into trouble.

 

[Baluncore]

The quadrature encoder (which you are discussing) is not very sensitive to contact bounce, but an absolute encoder may get into trouble.

Faulty components should be replaced.

An absolute encoder will use some form of Gray code. The elegant thing about a Gray code is that, like the quadrature encoder, only one bit ever changes at the time.
https://en.wikipedia.org/wiki/Gray_code#Position_encoders

Jitter and noise removal from an absolute encoder that uses a Gray code follows exactly the same process as is used with the quadrature encoder. When an input bit changes, sample all the other bits that did not change. That is easily done with a microcontroller using “word wide” boolean operators XOR, AND and OR to detect, mask and write the parallel bits into the virtual register.

The stable Gray code can be converted to a binary number by the same microcontroller using the XOR and shift operations.
https://en.wikipedia.org/wiki/Gray_code#Converting_to_and_from_Gray_code

 

[Baluncore]

Here is an algorithm that will clean up the Gray Code from an absolute encoder with a maximum lag of one step. It will also debounce or debobble two bit A~B code.

The Gray code input now is x_now. The previous code was x_was, the clean position register is master. x_diff will be the bits that have changed, zeros will be the 0s to insert, ones the 1s to insert.

x_diff = x_was EXOR x_now
If x_diff is zero you can stop processing here.
zeros = x_now OR x_diff
ones = x_now AND NOT( x_diff )
master = master AND zeros
master = master OR ones
x_was = X_now

Done.