I can't really see why this problem should accure.......

Or maybe I did'nt explain too well what I mean.

Lets call the two channels "Count" and "Direction"
The "Count" is always interrupted on change with the
capture-input. It the last interrupt was on falling edge
 the next must be on rising edge. The "direction" is neverconnected to an interrupt. So if I'm very close to the "Direction"
leading edge I would not get any interrupt (ever). If I'm very close to the "Count" leading edge the following would appear:

1. I get an interrupt (on rising edge on "Counter").
2. I read the "Direction"-input and detects if it's high or low.
3. I get an interrupt (on falling edge on "Counter")
4. I read the "Direction"-input and detects that i has not changed
since 2 and then I don't count up or down.

To get a faulty count the resting position has to be very close
to both the "Direction" and the "Count" leading edge.....

Am I right or.....

Patric


-----Ursprungligt meddelande-----
FrŒn: PC :supercat@CIRCAD.COM Skickat:         den 21 april 1999 07:02
Till:   PICLIST@MITVMA.MIT.EDU
€mne: Re: Quadrature decoder

|The one and only problem you have to account for is that the resting
|position of the decoder is VERY close the the leading edge of one of the
|pulses.. ie if you bump the decoder slightly or it begins to wear, it would
|be all too possible to generate direction-indication pulses in one direction
|without even touching the knob..

What about regarding the four states of the encoder as (in CW order),
1X, X0, 0X, and X1?  Or, to put it another way...

State 0:
  Wait for first input lo.
  If second input lo, inc count and goto state 1.  Else dec and state 3.
State 1:
  Wait for second input hi.
  If first input lo, inc count and goto state 2.  Else dec and state 0.
State 2:
  Wait for first input hi.
  If second input hi, inc count and goto state 3.  Else dec and state 1.
State 3:
  Wait for second input lo.
  If first input hi, inc count and goto state 0.  Else dec and state 2.

Note that since this algorithm will always be waiting for an edge on the
input which *DIDN'T* change last, it won't have jitter problems the way
the more "normal" algorithm doesn.  Further, if the chip being used has
suitably-programmable interrupts, the decoding can be interrupt-driven
without excessive numbers of interrupts.

 <<Fil: ENVELOPE.TXT>>