This is a classic case of not using enough hardware to do the job and the
software alone cannot solve the problem.

If only the A line is connected to an interrupt then any physical
oscillation around an A line transition will cause a number of interrupts.
Just looking at the B line to see if a counter should be incremented or
decremented doesn't work because the B line won't change for some time and
you accumulate false pulses.  If you OR the A and B line together and use
the result to interrupt the processor you can use a flag to determine which
way to modify the counter.

For example:

Interrupt! 'A' line just went high.
  if AFlag == 0 then
    if 'B' line is low
       increment counter
    else if 'B' line is high
       decrement counter.
    Set AFlag = 1;
  fi;

Interrupt! 'A' line just went high. (Again)
  if AFlag == 1
    ignore jitter.

Interrupt! 'B' line just went high.
  Set AFlag = 0;

The encoder can oscillate around the B liine as much as it wants because all
it does is clear the flag.  Notice that there is always only one place where
each variable can be modified.

The down side here is twice as many interrupts.  Also this algo. only counts
the number of encoder lines;  it's not quadrature counting each edge.  If
the I/O port you are using can produce an interrupt from either 'A' or 'B'
rising, or falling, than no extra hardware is needed.

At 04:39 PM 10/02/1997 +0100, you wrote:
>>>>I have used this approach for encoder used in a satellite antenna to read
>>>>azimut angle. Got problems with some false pulses which occured when the
>>>>encoder is just giving pulses when stopped (wind movement). When this pulses
>>>>are in the output connected to the interrupt you will get a false count.
>>
>>
>>I don't understand the problem, yet.
>>If the signal causes an interrupt couldn't you just reference the OTHER
>>signal to see if there's been any movement (just as Paul described)?
>
>The problem is that encoder is just slightly moved, so it does not produce a
>true quadrature pulse output as the rotation angle is less than a true
>encoder step. If that pulse triggers the interrupt and you reference to the
>other signal you will ever detect the same level. In fact, the level in this
>line doesn't change.
>
>> If the wind was causing pulses, then why couldn't you
>>decrement/increment the 'degree-of-turns' register accordingly to keep
>>track of subtle movement?
>
>In fact the best thing is to IGNORE those pulses while the antenna is
>stopped. You get the pulses but they don't indicate true encoder movements.
>If you count them you'll get an error and if you look at the other line to
>detect direction (up/down) you will get the same direction all the time. In
>a few days your encoder counts will not correspond with the encoder position.
>
>Don't know how to explain it better, but this problem is something hard to
>see in the theory and easy to get in a real system, with a big antenna dish.
>
>>
>>-Pete
>>peter.cesarz@appl.ge.com
>>
>
>
>Luis Fernandez Cormenzana
>RadioBit Sistemas, S.L.
>        Vehicle fleet control systems
>        Patrol presence controllers
>
>Fax/Tel:+34-6-585 64 57
>e-mail: radiobit@dragonet.es
>http://www.dragonet.es/users/radiobit
>
>
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9