It occurred to me while I wrote up my latest rotary encoder decoding routine that one could do a small amount of error correction as well. I wanted to see if anyone had run into such an attempt before, and had any advice or thoughts regarding it. This is concerning a normal rotary encoder with gray encoding - one output is 90 degrees out pf phase from the other, and only one bit changes at a time: A B 0 0 0 1 1 1 1 0 0 0 My current method takes the previous state (two bits) and the new state (two bits) and concatenates them into a four bit number. I then use a 16 position RETLW table to return -1, 0, or 1 depending on the 4 bit number. Encoder state byte: 0 0 0 0 Aold Bold Anew Bnew This works great, and is very quick. My particular method holds the old state in an 8 bit variable, and simply shifts it over two bits when a new state is ready, then chops off the top four bits. It occurred to me, though, that if I didn't chop off the top four bits (which are the results of the last two states, or in others words I have three old states and the new state in one 8 bit block) then I could use that history to determine the direction the encoder was going when it skipped bits. If the four samples were A B 0 0 (oldest state) 0 1 (older state) 1 1 (last state) 0 0 (newest state) Then this last state change from 1 1 to 0 0 could be counted as 2, rather than thrown away as an illegal change. This would take a 64 or 256 entry table, rather than 16 entries, but it would be just as fast. Faster, even, since I wouldn't have to clear the top four bits every time I got a new sample. Of course, I've done the calculations and this shouldn't occur (ie, I'm polling them faster than they should change - no interrupts at the moment), but I'd like to be able to lower the processor speed and the overhead of the polling routine as much as possible. I don't see any obvious problems, but I imagine this is not a new idea and there must be a reason why I haven't seen it discussed before. I can see why this wouldn't be on hardware decoders (event driven state machine, not polling - usually with glitch suppression), and very fast interrupt driven routines might never need it. -Adam -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Moving in southeast Michigan? Buy my house: http://ubasics.com/house/ Interested in electronics? Check out the projects at http://ubasics.com Building your own house? Check out http://ubasics.com/home/ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist