# Avoiding false optical rotary encoder readings

I have an optical shaft encoder that has rather big resolution - 2500 pulses per rotation. The problem is that false pulses get registered from environmental vibrations - if I shake it in my hand or slap a hand holding it with other hand - I get several pulses forth, then several back, then forth again - it looks like decaying sinusoide.

One way to deal with that is to count some amount of pulses that are in the same direction before registering "ok, the rotation has started".

Does anyone know some clever tricks to deal with this kind of problem in microcontroller code?

• Why do you need a clever trick for this? You already have an excellent idea. Oct 13, 2012 at 20:47
• the idea I have is just straight forward, I'm more interested in stories "from the trenches" about solving these issues Oct 13, 2012 at 20:50
• Program a Low Pass Filter in a Finite Impulse Response algorithm. Requires a bit of math to calculate the values for the taps, but the filter itself is quite fast. Oct 13, 2012 at 20:55
• Can you post a photo of the setup including the encoder? Oct 13, 2012 at 21:03
• I don't have the setup ready yet, just the encoder: metrology.precizika.lt/pic/Products/A58.jpg metrology.precizika.lt/pdf/A58_EN.pdf Oct 13, 2012 at 21:34

[...]count some amount of pulses that are in the same direction before registering "ok, the rotation has started"

A kind of hysteresis is proposed by the O.P. If there is a slow but real motion, your actual input will be slow and smooth, but it would be perceived as a series of steps.

First thing that come to mind is low-pass filtering your signal in software. Boxcar average (sliding average), for example, is nice and simple.

Second thing that comes to mind is isolating the encoder from unwanted vibration.

P.S.

There are several philosophies.

Philosophy #1. Attempt to solve optical problems with optics, mechanical problems with mechanics, analog problems with analog, digital problems with digital, software problems with software. In that order or precedence (roughly).

Philosophy #2. Try to solve every problem with software, because software changes are more expedient than hardware changes. If it can't be helped with software, try digital solution. Then try analog... Notice that the order is reversed w.r.t. Philosophy #1.

You have a very high resolution optical encoder and it's detecting real movements just as it's meant to. What's the problem?

Why do you have such a high resolution encoder if you don't want to measure such tiny movements? These two things seem like a contradiction. If you don't want to be able to measure such small movements, I have three suggestions:

• Improve your mechanical set up so that small vibrations aren't transmitted to the encoder so much. Are you using proper bearings everywhere?
• In software, take your calculated encoder position and right shift it by 2 or 3. (I.E. divide it by 4 or 8). This will basically simulate a much lower resolution encoder, which won't suffer from these problems so much.
• Send me the encoder, and I'll send you a much lower resolution one, for free!
• you are right, the encoder is too good for our purposes, but again - with encoder of any resolution you can get it to stop near the edge of slot and get false readings form vibrations Oct 13, 2012 at 21:37
• @miceuz, so you get a reading indicating a small movement (e.g. a single step)? Why is it a problem? If you have some kind of control loop around the encoder position that will over-react to a small position change, maybe the answer is fix the response, not try to degrade the encoder capability. Oct 13, 2012 at 22:57