Maker Pro
Maker Pro

Rotary encoder bounce problem

A

Adrian Jansen

Jan 1, 1970
0
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
 
P

Paul Burke

Jan 1, 1970
0
Adrian said:
Hi All,

I have used mechanical rotary ( quadrature ) encoders for years in various
applications...
Recently we changed over to one of the Piher 11mm encoders with 30 detents
and 15 cycles per rev... but seem to have terrible contact bounce....

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..

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
 
J

Jeroen

Jan 1, 1970
0
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
 
S

Spehro Pefhany

Jan 1, 1970
0
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.

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
 
F

Fred Bloggs

Jan 1, 1970
0
Adrian said:
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.

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.
 
T

Tim Wescott

Jan 1, 1970
0
Jeroen said:
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.

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.
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.

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.
Hope this helps,

Jeroen




low -

Sounds like you need a different brand of encoder.
 
S

Spehro Pefhany

Jan 1, 1970
0
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.

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
 
T

Tim Wescott

Jan 1, 1970
0
Spehro said:
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

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.
 
S

Spehro Pefhany

Jan 1, 1970
0
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.

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
 
B

Ben Bradley

Jan 1, 1970
0
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.

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.
 
P

petrus bitbyter

Jan 1, 1970
0
Adrian Jansen said:
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

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
 
A

Adrian Jansen

Jan 1, 1970
0
Jeroen said:
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

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
 
A

Adrian Jansen

Jan 1, 1970
0
Spehro Pefhany said:
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

Spehro,

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

Regards
Adrian Jansen
 
A

Adrian Jansen

Jan 1, 1970
0
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
 
F

Frank Bemelman

Jan 1, 1970
0
Adrian Jansen said:
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.

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.
 
A

Adrian Jansen

Jan 1, 1970
0
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
 
F

Frank Bemelman

Jan 1, 1970
0
Adrian Jansen said:
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.

? 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.
 
P

petrus bitbyter

Jan 1, 1970
0
Adrian Jansen said:
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

news:[email protected]...

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
 
S

Spehro Pefhany

Jan 1, 1970
0
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

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
 
J

Jeroen

Jan 1, 1970
0
Spehro Pefhany said:
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.

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
 
Top