Rotary encoder bounce problem

[Adrian Jansen]

No, I am not doing anything wierd with the micro ports. In fact when the
scope picture I posted was taken, the micro was disconnected. I wanted some
answers to a simple question, and got them, thanks to all, but I certainly
didnt create some odd setup just for the fun of it.

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control
"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:307mb01uep8ckvien9n0itbjc3fnh69hbs@4ax.com...

On Mon, 31 May 2004 11:30:02 +0200, the renowned "Frank Bemelman"
f.bemelmanx@planet.invalid.nl> wrote:

"Adrian Jansen" <qqv@noqqwhere.com> schreef in bericht
news:40ba9483@duster.adelaide.on.net...
I posted an image of the rotary encoder bounce to
alt.binaries.schematics.electronic

Same topic as here.

The strange thing is that when contact A opens in a normal way,
the voltage rises from 0V to 2.5V and then rises slowly furhter,
but when it opens due to bouncing, it rises from 0V to 4V ????

How do you do that? Can we see a piece of schematic showing
the encoder, filter and uC inputs?

I'm thinking maybe he's triggering an interrupt from the falling edge
of B, which is doing something unpleasant in sofware via both the A
and B "inputs". Is it an 8051-style pseudo-bidirectional port?

(Re?)writing the 1's to such a port (as you do for an input)will
momentarily turn on the "strong" transistor pullups for a fixed period
of time. Maybe changing any port bit (to high?) will do this (RMW on
the port), but that's more detail than I try to remember, and I've
never run into any problems to really burn the data in. ;-)

Anyway, disconnect the micro, look at the data lines, and you'll know
very quickly.

Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers:
http://www.trexon.com
Embedded software/hardware/analog Info for designers:
http://www.speff.com

 

[Tony Williams]

In article <40bc1430@duster.adelaide.on.net>,
Adrian Jansen <qqv@noqqwhere.com> wrote:
[snip]

Power supply and long line bounce are not an issue here. In fact
the whole power supply, encoder lines and processor are within
about 1 inch of each other. All the problems stem from within
the encoder.

Yes, your photograph clearly shows Switch A
glitching to an open-circuit when it shouldn't.

Since the glitches look to have identical timings
on the A and B channels they probably come from
a common fault, which is the Common connection
glitching to an open-circuit.

Fred was right some time ago, they are faulty
switches. They either have a manufacturing fault
or (worse still) an 'undocumented design feature'.

Matters can be improved slightly by changing the
two RC timings.... a slow (2mS) response to confirm
switch openings, and a much faster capacitor discharge
when a switch closes.

R1 R2
5v+---/\/\---+---/\/\---+--->uP logic-1 Vthresh.
| |
+ |
Switch A or B/ ===C
+ |
| |
Common +----------+---0v

Time-constant R1*C should be set so that it takes
2mS for the voltage across C to go from 0v to the
logic-1 Vthreshold of the uP. If possible use an
input that has a defined Vthreshold (like a comp
input). Rough values for R1*C= 200k*10nF.

Time-constant R2*C should be as short as possible,
to ensure that any switch closure (even one in the
middle of a glitch) discharges C to as near to 0v
as possible. If the switch has an Imax spec, then
R2 = 5v/Imax. Rough guess for R2 is 1k to 5k.
A 5k would take about 0.25mS to discharge a 10nF
capacitor from 5v to about 50mV.

--
Tony Williams.

 

[Rich Grise]

"Adrian Jansen" <qqv@noqqwhere.com> wrote in message

I am still playing with Frank's suggestion of fast polling the lines with
a
timer, and doing no debounce, but still have to get the software right for
this.

Edge trigger an interrupt on _everything_, and lock out interrupts for the
longest period of garbage that you've noticed + ~ 10-20%, and act on what
the states are after the lock-out, and last sample.

lessee...
_________________ _______________
| || | | |
| || | || |
| | | || |
___| |________|||_______|

_________________ _______
| || | | |
| || | || |
| | | || |
____________| |_________|||_____|

__ __ __ __ __
_______________| |_____| |_____| |______| |____| |____

interrupt -----^
lock out -------^^
sample -----------^

HTH!
Rich

 

[Frank Bemelman]

"Tony Williams" <tonyw@ledelec.demon.co.uk> schreef in bericht
news:4cb7f389d3tonyw@ledelec.demon.co.uk...

In article <40bb78eb$0$1764$c3e8da3@news.astraweb.com>,
Frank Bemelman <f.bemelmanx@planet.invalid.nl> wrote:

I've copied it to here:
www.planet.nl/~bemel141/images/Rotary_Encoder_bounce.jpg

Got it, thank you Frank.

There must be something really funny going on here.

Both A and B jump with the same timing. So it looks
as though the Common connection (inside the device)
is bouncing to an open-circuit at every closing edge
of B.

It might also do it on the opening edge, but A and B
are both already open-circuit at that instant, so any
open-circuit bounce of the Common would not be seen.

That's a hell of nice encoder I honestly can't imagine
that a manufacturer would make and sell such rubbish.

This is not something that should be 'fixed' only by a software
change, imo. I suppose that you could increase the polling rate by
a factor of ten, and digitally filter A & B in software, before
committing it to the decoding algorithm, but it all remembers me
too much of mending an old car I once owned.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

 

[Spehro Pefhany]

On Tue, 1 Jun 2004 15:26:37 +1000, the renowned "Adrian Jansen"
<qqv@noqqwhere.com> wrote:

No, I am not doing anything wierd with the micro ports. In fact when the
scope picture I posted was taken, the micro was disconnected. I wanted some
answers to a simple question, and got them, thanks to all, but I certainly
didnt create some odd setup just for the fun of it.

Okay, well Tony Williams nailed it on the RC networks. At this point,
I'd suggest you might have a defective encoder.

Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[petrus bitbyter]

"Adrian Jansen" <qqv@noqqwhere.com> schreef in bericht
news:40bc1430@duster.adelaide.on.net...

I can see why the slow rise after 2.5v or so on a normal transition. I
have
100 k pullups direct on the encoder lines, then a series 100 k resistor to
a
10 nF cap to earth, and the processor pins - which are high impedance
inputs. The scope probes were directly on the encoder lines for the
picture.
So when the encoder is spun, the cap charges to around 1/2 rail on
average,
and then the line is released by the encoder switch. So you get a fast
rise
to the cap average voltage, then slow as the cap charges through the 100 k
resistors. But when the cap voltage is already high because the encoder
line has been high a while, and bounces low, it returns high - to the cap
voltage - almost instantly.

We could use lower pullups, but when I designed it this way, I was
expecting
contact bounce, and wanted a timeconstant of around 1 msec, with
reasonable
size caps. Power drain is also somewhat an issue. These encoders leave
both lines held low on alternate detents, so the pullups draw current. I
could afford 10 k, ie 1 ma drain total, but not 1 k.

Power supply and long line bounce are not an issue here. In fact the
whole
power supply, encoder lines and processor are within about 1 inch of each
other. All the problems stem from within the encoder.

Interestingly, when you rotate the encoder (say) clockwise, you only get
bounce on the A line when the B line transitions, and only when you rotate
a/c do you get bounce on the B line from the A transition. This
definitely
makes me think the problem is within the encoder mechanism itself.
I just tried another encoder of the same type - probably the same batch -
since the supplier only had 6 in stock - and it does exactly the same,
although perhaps not as often.

I am still playing with Frank's suggestion of fast polling the lines with
a
timer, and doing no debounce, but still have to get the software right for
this.

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control

Looking at the picture more carefully (even enlarged it) I cannot find an
explanation in the electronics that fits everything we know. So I'm pretty
sure you're right to pay attention to the encoder itself. To us - simple
minded engineers - the encoder only has two switches: A and B with one
common connection. But looking carefully to the bounce pulses I suspect
there are more switching contacts in that black box. The bouncing pulses are
not only similar, they are equal. I cannot but conclude that there is a
relative low impedance between A en B during that pulses. To be more
precise, it looks like the common is disconnected from GND during that
bounce pulses. As that (dis)connection is inside the encoder, you cannot do
very much from the outside. Low pull ups will not help. I think the debounce
circuit as advised is meant to minimize these bounce effects. You have to
debounce both signals on every edge. Which should not be a problem as long
as the debounce times last no longer then the minimum time between two
edges. So you're back on START again.

If this is the only parasetic switch, you can try to kill the short positive
pulses with a diode and an RC.


---------------+---------- VCC
|
|
.-.
| |
| |
'-'
|
+-----+---|<---+
| | +-----------o
| .-. |
--- | | \ o
--- | | \ A
| '-' \.
| | o
| | |
| | |
| | \ o
| | \ P
| | \.
| | o
+-----+--------+------------
|
===
GND

created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de

It is very clear that the assumption to have a stable A signal when B is
changing (and B stable when A is changing) I mentioned earlier, is *not*
true.

I'd like to have the thing to find out what's going on inside. You sure have
to do some more analisys before you can decide how to handle it. I still
doubt wether you'll ever be able to make a reliable circuit with it but you
(and I) can't be sure until you find out what's really happening inside.

petrus bitbyter










---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.688 / Virus Database: 449 - Release Date: 18-5-2004

 

[Fred Bloggs]

Spehro Pefhany wrote:

Okay, well Tony Williams nailed it on the RC networks. At this point,
I'd suggest you might have a defective encoder.

Best regards,
Spehro Pefhany

Nah- actually the retard has a spec encoder: CL11CTV1Y22LFACF at
http://www.piher-nacesa.com/product.htm click the CL -11 11mm
incremental encoder. The 15 pulse version has detents at 180o and the
spec clearly illustrates "sliding contact noise" or breaks in the
contact at exactly these detent positions- not to exceed 2ms duration at
360o/sec or less rotation rate. It is basically working as advertized.

 

[Spehro Pefhany]

On Tue, 01 Jun 2004 11:39:51 GMT, the renowned Fred Bloggs
<nospam@nospam.com> wrote:

Spehro Pefhany wrote:


Okay, well Tony Williams nailed it on the RC networks. At this point,
I'd suggest you might have a defective encoder.

Best regards,
Spehro Pefhany

Nah- actually the retard has a spec encoder: CL11CTV1Y22LFACF at
http://www.piher-nacesa.com/product.htm click the CL -11 11mm
incremental encoder. The 15 pulse version has detents at 180o and the
spec clearly illustrates "sliding contact noise" or breaks in the
contact at exactly these detent positions- not to exceed 2ms duration at
360o/sec or less rotation rate. It is basically working as advertized.

Okay, yes, I see it in "TEST CIRCUIT DIAGRAM" and the specs. So, a few
ms of debounce in software will take that out. Just poll the inputs at
a few hundred Hz and require that the previous sample and current
sample agree before passing on the change- it's no big deal.

Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Spehro Pefhany]

On Tue, 01 Jun 2004 11:09:12 GMT, the renowned "petrus bitbyter"
<p.kralt@reducespamforchello.nl> wrote:

I'd like to have the thing to find out what's going on inside. You sure have
to do some more analisys before you can decide how to handle it. I still
doubt wether you'll ever be able to make a reliable circuit with it but you
(and I) can't be sure until you find out what's really happening inside.

This is what's inside the ones we have (18 pulses per revolution):

www.speff.com/encoder_rotor.jpg
www.speff.com/encoder_stator.jpg
www.speff.com/encoder_shaft_bushing.jpg
www.speff.com/encoder_switch.jpg

The contacts are packed with a suitable lubricant.

As you can see there are three rotating contacts (connected together)
that short one of the six fingers on each side to the common (at the
bottom). All three are in use at any given time. Very clever and
simple- provided you can make the stamped parts and plastic parts
precisely enough that the assembly meets the "timing" specs.

The detents are created by the fixed spring you see in the
shaft_bushing photo working against a pattern molded into the back of
the rotor (not shown in photos), again with suitable lubricant.

Data sheet for this part:
http://www.trexon.com/pdfs/trexon_encoder_revA.pdf

Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Frank Bemelman]

"Fred Bloggs" <nospam@nospam.com> schreef in bericht
news:40BC6B02.8040501@nospam.com...

Spehro Pefhany wrote:


Okay, well Tony Williams nailed it on the RC networks. At this point,
I'd suggest you might have a defective encoder.

Best regards,
Spehro Pefhany

Nah- actually the retard has a spec encoder: CL11CTV1Y22LFACF at
http://www.piher-nacesa.com/product.htm click the CL -11 11mm
incremental encoder. The 15 pulse version has detents at 180o and the
spec clearly illustrates "sliding contact noise" or breaks in the
contact at exactly these detent positions- not to exceed 2ms duration at
360o/sec or less rotation rate. It is basically working as advertized.

Then he also better follows the guidelines and use 10K resistors with
his 10nF caps. With the 100K resistors, it may not work very well,
when someone turns the knob a bit faster.

But I still find this a crappy encoder. A sensible manufacturer
should know that we don't expect such noise in the middle of a
pulse. Hiding it in the specs doesn't make it any better.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)