SkinTech wrote:
>
>[sorry, send at first without tag. therefore resend]
>
>Hi all,
>
>I always try to solve my own problems (I learn from it) but this one has me
>stumped.
>My project has a 16F74, reading the output of a rotary encoder (2 bit), see
>below.
>First I check by polling if there is a change in the 'A' bit. If so, I wait
>some 10mS (debounce) and then look again. If there is still a change, I
>check if it is 1>0 or 0>1. In each case, I then check the 'B' bit to
>determine direction. For debugging I beep once (CW) or twice (CCW) the
>buzzer.
>When turning the encoder I get seemingly random results. Sometimes it beeps
>3 times, or 4 times, or 1 time, or not at all over half a revolution. Then
>it starts again. I'm pretty sure it has to do with the debounce, but I
>can't
>get it right. I must add that the beep adds another 10 or 30 mS delay
>between pollings.
>The encoders are spec'd at <5mS chatter.
>
>Has anyone experience with decoding rotary encoders? Any help or ideas
>would
>be greatly appreciated.
>
>
>Jan Didden
>SkinTech
>
>; This is how I think the encoders work:
>;The encoders output a 2-bit value:
>; the A-bit signals rotation,
>; the B-bit signals the direction of rotation. (actually A and B are
>interchangable of course)
>; encoder movement is detected by polling PORTB and debouncing.
>;
>;         --------------------->cw
>;    channel A     ___       ___       ___  [channel A leads channel B]
>;                 ___|      |___|      |___|
>;
>;       channel B    ___        ___        ___
>;                  |___|       |___|      |___|
>;
>;
>;
>; CCW: channel A      ___        ___        ___ [channel A trails channel
>B]
>;                          ___|       |___|      |___|
>;
>;           channel B    ___       ___       ___
>;                           _|      |___|     |___|
>;
>;     A-bit       B-bit      Direction
>;     0>1           0           CW
>;                       1           CCW
>;     1>0           0           CCW
>;                        1           CW
>
>--

Unless you're working with a *very* coarse encoder, there are probably a lot
more transitions happening than you might realize.

The 10 mS debounce is probably a bit much and may be contributing to the
problem. I would expect that 5 mS or so would be sufficient. This would
depend a great deal on whether you are using the encoder for position
sensing (more debounce) or for speed sensing (less debounce).

Another thing you might try is to remove your beeper timing from the
program. If you can trigger a one-shot (a 555 timer or such) to time your
audible feedback, then that complication (and timing uncertainty) will not
be adding to your debugging task.

(BTW, there was a suggestion on the [EE] thread to ignore the 1->0
transition on the A channel. Be aware that doing so will reduce your
resolution by half. Since you are ignoring B channel transitions and using
it as only a direction bit, you have already reduced your  available
resolution by half. Depending on your application, this may or may not be a
problem.)

Regards, Bob


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics