Searching \ for 'Encoders and jitter' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/sensors.htm?key=encoder
Search entire site for: 'Encoders and jitter'.

Truncated match.
PICList Thread
'Encoders and jitter'
1997\02\13@012931 by Bob Blick

flavicon
face
John Payson is right. As long as only one bit jitters back and forth, you
don't need to test the two encoder lines any faster than the maximum count
rate you expect. The count is only jittering back and forth between the
same two numbers, and if you miss some of the jitter, you don't miss any
real counts, because the count is always accurate when you sample the pins.

If the jitter involves both bits, then you have a problem, but in that case
I would suggest that the mechanical aspect of your device needs to be
looked at(backlash or slop reduction), or you need to sample the encoder
faster than the physical limits of the system.

-Bob

1997\02\13@032144 by Mike

flavicon
face
At 10:23 PM 12/02/97 -0800, you wrote:
>John Payson is right. As long as only one bit jitters back and forth, you
>don't need to test the two encoder lines any faster than the maximum count
>rate you expect. The count is only jittering back and forth between the
>same two numbers, and if you miss some of the jitter, you don't miss any
>real counts, because the count is always accurate when you sample the pins.
>
>If the jitter involves both bits, then you have a problem, but in that case
>I would suggest that the mechanical aspect of your device needs to be
>looked at(backlash or slop reduction), or you need to sample the encoder
>faster than the physical limits of the system.

The whole point in my original response to the first thread was:-

       Interrupt prcoessing using the MC68705P3 was ideal since we could
       generate the actual inc or dec instruction direct from the output
       of the decoder chip which read the phases A and B.

This approach was ideal in that it allowed several other operations, the
control/display routines only had to check a register and not sample the pins,
the software complexity was reduced and the allowed input frequency could be
much higher than a conventional software approach - such as used on the PICs.

Prior to the interrupt trick we finally used, we went through the whole arena
of issues covered here and determined that (then) a software approach of just
sampling the pins was far too slow and limited flexibility - we could not
readily perform other tasks. Anyway all this was solved by the interrupt trick.

In fact I'm dissapointed that a lot of the tricks we did with the 68705 series
cannot be done on the PIC - such  as generating an instruction on a port and
branching into RAM to execute a modified table access/search etc.

Rgds

Mike

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...