Unexpected results from Encoder::GetRate()

[vamfun]

Originally Posted by Alan Anderson

No, it's just a counter with a direction input. It happens to work with a quadrature encoder if you don't have "noisy" rotation. If the encoder happens to oscillate a bit back and forth at the A channel transition, you'll get false counts.

That exact situation happened on our "Triple Play" robot. We had quadrature encoders on miniature omniwheel-ish rollers to track our motion on the carpet. We could watch the wheels not spin appreciably while the code told us they were making several revolutions. I fixed it by implementing a true quadrature decoder. Something almost exactly like my code was independently developed by Kevin Watson and incorporated into his Encoder.c library for the IFI controller.

I call it quadrature only since it is uses the quadrature information, even though it might be a weaker algorithm. Perhaps it takes some liberty with industry conventions.

You make a good point Alan, regarding the sensitive nature of my scheme to vibration that can cause oscillation about an edge. It will certainly do what you said... but it is the price that must be paid if you want to use fewer interrupts. If this is not a constraint, then clearly the use of both rising edge and falling edges will help as you discovered.

These are the mappings as I see them:
my 1x scheme
1x , 1 interrupt per cycle, sensitive to edge oscillation,
rate sensitive to rising edge phase errors of A channel
A (rising) B (low) increment
A (rising) B (high) decrement

2x , 2 interrupts per cycle, not sensitive to oscillations
rate sensitive to rising and falling edge phase errors of A channel
A (rising) B (low) increment
A (falling) B (high) increment
A (rising) B (high) decrement
A (falling) B (low) decrement

4x , 4 interrupts per cycle, not sensitive to oscillations
rate sensitive to rising and falling edge phase errors of both A and B channels

A (rising) B (low) increment
B (rising) A (high) increment
A (falling) B (high) increment
B (falling) A (low) increment
A (rising) B (high) decrement
B (rising) A (low) decrement
A (falling) B (low) decrement
B (falling) A (high) decrement

Making a 1x insensitive to oscillations could be done a number of ways:
One simple mapping is to enable count when B (low) and count when B(high)
This requires B transitions for counting.
So..
1x, 2 interrupts per cycle, not sensitive to oscillations
rate sensitive to rising edge phase errors of A channel
A (rising) B (high) increment , reset enable
A (falling) B (high) decrement, reset enable
A (rising) B (low) enable count
A (falling) B (low) enable count

Ill have to go back and review how Kevin did his. Its been a while.