0
\$\begingroup\$

I've just bought Waveshare rotation sensor.

I connected it to Logic Analyzer and made some tests. As expected the sensor sends two low-level signals moved in phase.

enter image description here

But when you zoom in it you can see many noise while changing level from high to low or from low to high as long as voltage will not get stable. Here is an example.

enter image description here

The noise continues for several microseconds so it is a problem because if I want to register user action from sensor in microcontroller it register falling-edge (as expected) but often (not always) also the noise. As a result I get a few interrupts instead of real one.

1. Is this noise natural behaviour while shaking the rotation shovel?

2. Is any way to eliminate this noise because communication with the microcontroller?

\$\endgroup\$
  • \$\begingroup\$ Looks like contact bounce. Probably low quality product. \$\endgroup\$ – Chu Sep 27 '17 at 17:29
  • \$\begingroup\$ Welcome to EE.SE. Please add datasheet links to any devices mentioned (other than standard components). \$\endgroup\$ – Transistor Sep 27 '17 at 18:02
1
\$\begingroup\$

This is normal behavior for most of mechanical encoders (rotation sensors). Similar problem is met when using switch connected to microcontroller pin.

Solution? Use simple debounce circuit (capacitor + resistor), more complicated debounce circuit (buffer/gate with Schmidt input) or create debounce code.

When touching the shaft there is a chance the encoder is on the edge between on and off, so it can give 'false signals' or just toggle between 1 and 0. Good debounce code should eliminate the mess.

\$\endgroup\$
0
\$\begingroup\$

This is pretty much normal behaviour of all encoders be they mechanical or optical or whatever. When traversing an edge the output is really indeterminate and susceptible to both electrical and mechanical "noise".

It is therefore prudent to properly use the quadrature information. Do not rely on single edges for position information. You need to rely on the relative information supplied by the two lines.

In your example you need to treat the second trace information as.. it moved forward a little, moved back, moved forward again etc. etc.

It is not until you see a transition on the other signal that you can safely ignore edges on the first one.

If you do that correctly it does not matter if there is erroneous bouncing or noise induced edges in the signal.

\$\endgroup\$
0
\$\begingroup\$

What you have is a quadrature encoder. There are two outputs which are 90° out of phase. (90° = quarter of a turn, hence quadrature.) To keep track of position it's a matter of keeping track of the count using an up-down counter.

schematic

simulate this circuit – Schematic created using CircuitLab

Figure 1. 2-bit rotary encoder waveforms.

The program logic is very simple.

  • Track the current state of 'A'. If the state changes to 'high' then:
  • Look at input 'B'. If 'B' is low then count up. If 'B' is high then count down.

You'll probably need to debounce the inputs to prevent spurious triggering.

Interrupt driven

To make the encoder tracking interrupt driven you just need to have one phase ("A" in the example above) trigger the input. The interrupt handler then looks at B to determine whether to count up or down.

Removing debouncing a direct interrupt driven input

schematic

simulate this circuit

Figure 2. If interrupt triggers are possible on both rising and falling edges then there is no need for debounce.

Figure 2 doubles up the scheme of Figure 1 by counting on negative edges of 'A' but with inverse logic regarding 'B'. Here we can see that any bounce on either input results in a jitter of only one count.

\$\endgroup\$
  • \$\begingroup\$ Issue with your answer is it relies on the bouncing edges being far enough apart for a) the micro to detect them as two interrupts, and b) the code being fast enough to handle them that close together. \$\endgroup\$ – Trevor_G Sep 28 '17 at 16:40
  • \$\begingroup\$ That is a fair observation. I'd be interested to see a flowchart for your scheme. [That should keep you busy for an hour. ;^)] \$\endgroup\$ – Transistor Sep 28 '17 at 16:46
  • \$\begingroup\$ LOL no doubt :) Basically when using interrupts you need to detect one, check the other line's level to know where you are then lock out that interrupt and monitor the interrupt on the other line. Repeat.. \$\endgroup\$ – Trevor_G Sep 28 '17 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.