Hi Adam,

I have been working on a similar problem. My main problem is 'noisy' 
encoders so I was working on a predictive idea but am ending up in a mess.
Would be very interested to see your full routine

TIA

Dave


M. Adam Davis wrote:
> 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
>
>   
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist