Quote:
Originally Posted by vamfun
Note to Joe H: For your 1x, I don't like your algorithm because the count oscillates when stuck with an oscillating A edge over a BHigh or Blow state. I believe this can really aggravate the GetRate() noise.
...
You count up or down on the A edge transition if Bhigh so you oscillate between +1 and -1 increments. My 1x non-oscillating scheme and Kevin's will not do this. Mine will allow a single proper count in the normal direction and no change on the oscillatory reversal. Kevin's will not allow any count until B changes sign.
|
What's a proper count? If the lines did it, it gets decoded. It seems unreasonable for the decoder to make assumptions about what the sensor meant to encode. The way I've implemented it allows you to read the true position at any point independent of the rate calculation. I then address the concern you have for the rate measurement independently by ignoring any count that has changed direction for the purposes of calculating rate.
Because I'm using an FPGA, I can afford to implement the decoder correctly without regard for shortcuts in interrupt handling. The simple fact that your interrupt handler can't check the state of the B line at the exact instance that the A line edge is detected means that you have a race condition to count the wrong way anyway... and it's a pretty big hole with most interrupt handlers, especially on the PIC18F where you don't get hardware context saving and it's just generally a very slow processor. Without hardware support, you can't really trust the decoding in the face of noise.
-Joe