Connect with us

Rotary encoder bounce problem

Discussion in 'Electronic Design' started by Adrian Jansen, May 26, 2004.

Scroll to continue with content
  1. Hi All,

    I have used mechanical rotary ( quadrature ) encoders for years in various
    applications, always the type where the detent position leaves the lines
    high, so each detent corresponds to 1 full cycle of lineA high - lineA low -
    lineB low - lineA high - line B high, and of course the reverse for rotation
    in the other direction. Normally these need about 100 us of debounce on
    both lines, which we do with both some RC, and software - keep reading the
    lines until we get a stable repeat. Easy, and it always works.

    Recently we changed over to one of the Piher 11mm encoders with 30 detents
    and 15 cycles per rev. (Piher part number CL11CTV1Y22LFACF). These leave
    the lines alternately hi and lo on each detent, which is ok with a minor
    software change, but seem to have terrible contact bounce, which is a major
    problem. I used the recommended debounce circuit from Piher, 100k pullups
    on the lines, 100k series feed to the processor line, and a 1n cap to earth.
    But the contact bounce lasts for at least 2 msec, and often you get
    disturbance on the *other* line when one does a hi-lo transition. At 2 msec
    delay, you can spin the encoder fast enough by hand to miss pulses, which is
    a real niusance.

    We want to use these where its critical that we never miss a pulse, or get
    false extra pulses at low speed, but also where we dont miss too many pulses
    at high speed, so scrolling through around 10-50 pulses setting a number
    works reasonably well. So far I cannot see how to do this effectively with
    these encoders.

    Has anyone measured the contact bounce on this type of encoder from other
    sources, eg Alps, Tenrod, etc, and also whether there is any difference
    between the 30 detent/15 cycle versions and the 20 detent/20 cycle version.
    ?

    Anyone with other experience on these encoders is welcome to comment.

    --
    Regards,

    Adrian Jansen
    J & K MicroSystems
    Microcomputer solutions for industrial control
     
  2. Paul Burke

    Paul Burke Guest

    If your application really is critical, don't use those encoders. You
    can easily filter out both-lines bounce (by doing nothing on HH to LL or
    LL to HH transitions), but if the bounce period approaches the minimum
    state time, there's no way you can filter it and detect all state
    changes- in fact, you'll tend to skip 4 state bunches. I'd use non
    contact optical encoders.

    Paul Burke
     
  3. Jeroen

    Jeroen Guest

    what software method do you use to decode the information? You can designate
    one channel as a clock and the other as a direction, or you can use the
    state machine approach.

    I recently did an encoder project too, and the first method doesn't work
    that good. Then I switched to the state machine approach which is superior.
    The main problem is there can be a false situtation where one channel pulses
    but the other doesn't. With the state machine approach you step through the
    steps of the expected cycle, otherwise the pulses are ignored.

    So basically you wait for a rising edge on ch. A, then you wait for a rising
    edge on ch. B, then wait for a falling edge on ch. A, then for a falling
    edge on ch. B. Then you know you have a legal cycle. If ch. A has a rising
    edge, but it falls before B rised, you know this was an illegal cycle. The
    particular encoder I used generated many false pulses on one channel when it
    fell into the detent. The slightest movement of the knob would generate many
    pulses on that channel.

    Hope this helps,

    Jeroen
     
  4. Our mechanical encoders only have guaranteed state on one channel at
    the detent, and 5ms maximum bounce. It's not a problem if you do the
    firmware right- the "feel" is really very good. The RC networks the
    Japanese typically suggest are not necessary for "debouncing" either,
    but they would help with ESD.

    Best regards,
    Spehro Pefhany
     
  5. Fred Bloggs

    Fred Bloggs Guest

    Sounds like these encoders are intended to be operated with a discrete
    pause at the detent which means the controller must enforce the timing
    so that insufficient pause -something like less than 50ms- results in no
    valid input. You will need edge detection for rotation decode as well as
    time duration discrimination to make these work. Visual feedback of
    input is also necessary to "train" the operator in how fast he can spin
    the shaft.
     
  6. Tim Wescott

    Tim Wescott Guest

    I would _only_ use the state machine approach. One very nice thing
    about it is that for a pure position sense and a decent encoder you
    don't have to debounce at all -- hash on one line gets interpreted as
    the position bouncing up and down by one count, but you always settle to
    the right value in the end.
    This would be outside of my definition of a 'decent' encoder. If it's
    got detents then they should be mechanically aligned such that you don't
    see motion -- unless the encoder was designed (and specified) to put the
    detents right at the switching points, in which case your software
    should be ignoring that behavior at the loss of half your resolution.
    Sounds like you need a different brand of encoder.
     
  7. You most certainly do not want resolution that is finer than the
    detents. Typically you get 4 edges per detent on mechanical encoders.

    Best regards,
    Spehro Pefhany
     
  8. Tim Wescott

    Tim Wescott Guest

    I've had a lot of experience with high-resolution encoders for motion
    control, but I've only designed in one panel-mount encoder that sported
    a knob. That one had one edge per detent (not one cycle). The 4-edge
    per detent business is interesting -- it seems a great waste of sensor
    resolution.
     
  9. I guess it's a trade-off between the mechanical precision, the optimum
    number of detents and, of course, cost. The standard for the knob
    encoders is one cycle per detent, for whatever reasons, and most have
    relatively low resolution (around 20 detents for 360 angular degrees).
    I imagine you're more used to something like 1024 cycles per
    revolution.

    Best regards,
    Spehro Pefhany
     
  10. Ben Bradley

    Ben Bradley Guest

    The four edges per detent devices leave both switches open at the
    detent, so that no current is being drawn through pull-up resistors at
    the detent. This may be important in low-power and/or battery powered
    devices that are "on" all the time. If only (just to think of one
    application) electronic thermostats used these to set temperature
    rather than those little membrane-panel "up" and "down" buttons, which
    are of course a lot cheaper. than a mechanical rotary encoder and
    plastic knob.
     
  11. Adrian,

    A main property of this type of encoders is - or should be - that A and B
    never change at the same time. If they do, due to long debounce times, they
    are not reliable anymore.

    The basic way of debouncing I'm aware of is what I call the half pulse
    delay. It can be done either in hard- or in software. In short: Let A and B
    be the inputs and A' and B' be the outputs of the debounce circuit. If
    input A changes, output B to B' and if input B changes output A to A'. This
    way your bounce can last for half a pulsewidth without effecting the output.

    As I said, when the bounce lasts longer, you're stuck. The only solution I
    can think about is deafening the debounce circuit. Check the time of the
    pulses and when they become to short, stop listening until the pulses become
    long enough again.

    petrus bitbyter
     
  12. Thanks Jeroen,
    Because these encoders have a detent on every half cycle of the
    output, the state machine approach doesnt allow as much error
    checking, since each line only makes one transition between detents,
    alternately hi and lo.

    Regards
    Adrian Jansen
     
  13. Spehro,

    Can you provide a link to a source of the encoders you use ?

    Regards
    Adrian Jansen
     
  14. Thanks to all for the replies and discussion. I had some success
    after changing the caps to 10nf, creating a 1 msec time constant in
    hardware. Then in software allowing 2 msec after the IRQ before
    reading the state of the lines, and continuing to read the lines until
    I got 8 consecutive readings the same. I still got a false read when
    the line B transition put enough bounce on the line A ( the one I am
    using as the IRQ ) to trigger the IRQ, but its rare enough that its
    not going to be a major problem. But we will revert to the other type
    of encoder, which has 1 detent per cycle, rather than this type, which
    has 2 detents per cycle. The error checking can be made a lot better
    using the stat machine approach.
    I still think that any of these encoders with up to 2 msec bounce
    times are marginal at best. With 20 cycles per rev, its quite easy to
    spin them over 5-10 pulses, and miss several due to the bounce delay.

    Sorry for the repost, but I still cant see this post, or the repost,
    on my normal news server.

    Regards,
    Adrian Jansen
     
  15. That's why you shouldn't do any software debouncing. Poll your encoder
    with a fast timer interrupt, faster than the shortest time between
    ideal A & B transitions. In that case, contact bounce will only result
    in forward/reverse, your counter going up and down by one. Multiple
    readings as an attempt to get stability is a road to disaster.
     
  16. That only works for the encoder type with 1 detent per cycle, so you can
    wait for the lines to transition back to the rest state before re-arming the
    IRQ. When you have 2 detents per cycle, you have no way of detecting the
    'end' of a cycle. And of course if you get multiple IRQs because of bounce,
    you count multiple pulses.
    The only way of overcoming this that I can see would be to use IRQ's on both
    lines, but unfortunately I didnt allow for that in the existing design.

    --
    Regards,

    Adrian Jansen
    J & K MicroSystems
    Microcomputer solutions for industrial control
     
  17. ? If you poll your encoder with a timer interrupt, every 2mS or whatever,
    you don't need to use IRQ for transitions. Read A/B, see if they have
    changed since the previous timer interrupt and act accordingly.
     
  18. Adrian,

    There's no need for two IRQs. The only thing the IRQ-routine has to do is to
    find out which input line changed and setting an output bit accordingly. No
    other part of the program ever has to do with the bouncing encoderlines. It
    has to use the "output" bits I named A' and B' in a previous posting. If
    the existing program requires more action on that IRQ, make it a separate
    module or routine that uses A' and B'.

    You can extend the the main funtion of the IRQ-routine with an overrun
    handler. It has to keep track off the time elapsed since the last change in
    the outputs, either A' or B'. When the next change occurs within too short a
    time, it has to freeze the outputs until the pulse duration becomes long
    enough again. This way you will never miss a slow pulse and only a couple of
    the fast pulses. IMHO it is the best result you can achive using those
    unreliable encoders.

    petrus bitbyter
     
  19. I much prefer using polling techniques with mechanical encoders. THe
    results are reliable if the code is written correctly. Less than 1kHz
    (perhaps 400Hz) is sufficient for a knob mechanical encoder.

    Connecting an /IRQ to a "dirty" signal source seems like a recipe for
    the use of too much (and too variable) in the way of processor
    bandwidth, if not outright disaster.

    Best regards,
    Best regards,
    Spehro Pefhany
     
  20. Jeroen

    Jeroen Guest

    it only takes 6 components to debounce the lines in hardware, and with
    current sizes of components, it's not high a price to pay in term of board
    space. You can fit them nicely under the encoder, using almost no board
    space at all. I used an encoder with a integrated push button, but I
    debounce that in software, that's much easier then debouncing the encoder
    part.

    Jeroen
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-