> >It doesn't matter how fast the jitter is. If the signal at some time T0 is > >"00", and at some time later is "01", it doesn't matter how many times it > >went between "00" and "01", the result is still one count. All that matters > >is that the time the system is stable between unstable periods (and most > >reasonable sensors are stable when the mechanism isn't right near an edge) > >exceeds the maximum time between polling events. Provided that requirement > >is met, there is no need for debouncing or any other preprocessing. Any > >jitter "event" which goes from one state to another and back to the first > >state will be filtered out. > > I don't see it that way. If one transition is detected - ie generates a CPU > interrupt (which makes a count) and this is still being processed whilst it > goes back one transition then the result is the internal CPU count will not > relate to the actual position. If you are handling things properly, it won't matter what the jitter is. To see very simply why this is so, go to any normal light switch. Start with the light off. Flip the switch a bunch of times. I can glance at the light periodically and any time the light is stable I will know wheth- er you flipped the switch an odd or even number of times. It does not matter whether I see all of your switch flips; all that matters is that if I can see the light when it's stable I can tell how many times you've flipped the switch up to that point. > The solution - fastest possible decoder circuit, and as far as possible a > fully symetrical filter with a time constant about 1/4 of the maximum count > rate. We also reduced any extraneous sources of jitter - likethe hydraulic > pumps and positions of the feed lines etc. This all came before we could > get dedicated state machine chips running at 4MHz. An alternative solution, if you have seperate enable controls for your two interrupts, is to regard the four states of the system not as "00", "01", "11", and "10", but instead to regard them as "0T", "T1", "1T", and "T0"; your interrupt logic should then be as follows: enum {STATE_0T,STATE_T1,STATE_1T,STATE_T0} my_state; void init(void) { enable_int(pin1,high); my_state = STATE0T; } void interrupt(void) { switch(my_state) { case STATE_0T: if (pin2 == high) { count++; my_state = STATE_T1; enable_int(pin2,high); break; } else { count--; my_state = STATE_T0; enable_int(pin2,low); break; } case STATE_T1: if (pin1 == high) { count++; my_state = STATE_1T; enable_int(pin1,high); break; } else { count--; my_state = STATE_0T; enable_int(pin1,low); break; } case STATE_1T: if (pin2 == high) { count--; my_state = STATE_T1; enable_int(pin2,high); break; } else { count++; my_state = STATE_T0; enable_int(pin2,low); break; } case STATE_T0: if (pin1 == high) { count--; my_state = STATE_1T; enable_int(pin1,high); break; } else { count++; my_state = STATE_0T; enable_int(pin1,low); break; } } } Note that using this technique, the system will only be interrupted four times for each real cycle, regardless of how much jitter there is (provided only that the jitter isn't more than 1/4 cycle). Unfortunately, I don't think the PIC can implement the above very well, at least not on the lower-model PICs.