Worthless rotary encoders

[Jan Audio]

Why would they sell rotary encoders that give pulses on both pins ?
The pins are always high volt.

Am i being ripped off ?
Normally those china encoders work for me,
this time i ordered 100, placed them away for later use, and just found out they are not usable.

[mikerj]

Why would they sell rotary encoders that give pulses on both pins ?
The pins are always high volt.

All quadrature encoders give pulses on the two output pins.  You said you are seeing pulses on both pins, but then you say both pins remain at high voltage so I'm not sure what the actual problem is?

[MikeK]

Post a scope trace.

[MarkF]

The Bourns PEC11 encoders are that way.
  - They have pulses on both lines WHILE being turned.
  - With no movement, both lines are high.

[Jan Audio]

Hmz, how do i get the movement then ?
It always goes up with my code now.

[Jan Audio]

All quadrature encoders give pulses on the two output pins.  You said you are seeing pulses on both pins, but then you say both pins remain at high voltage so I'm not sure what the actual problem is?

Negative pulses, sorry.

[HB9EVI]

either you change your code to do the decoding or hardware-decode with a 74HC74; then a rotary encoder behaves like up/down buttons

[Jan Audio]

Well, i have my code in the main loop, no interrupts.
Hardware no, it is a finished project, i just need some new encoders.

So they are still usable with interrupts, intresting to test in a simple project soon.
Thanks.

Those alps are so expensive i cant afford them.
And mouser has so many options i stopped searching after opening the site.
Just going to order those alps for around 2 euro each, i make very expensive gear now.

Did i miss something when ordering ebay encoders ?
Could i have found out ?
I did not know there are so many options.

[Jan Audio]

Post a scope trace.

I have a single channel analog scope.
Waiting for a modern scope to come out anytime soon with better specs.

[HB9EVI]

personally I don't know any encoders which don't do gray code output, so I'm a bit surprised that you struggle with it now.
never mind whether I used magnetic, optical or mechanical encoders, they all worked the same way, with same code on mcu side
most of my projects run with those cheap china encoders, never had any unexpected behaviour with them

[Jan Audio]

I have these from ebay :
50PCS Rotary encoder code switch EC11 audio digital potentiometer with switch 5p

ITEM PRICE:
US $22.20

Glad i dont have 100.

What does that EC11 means then ?
Same as the bourns ?

[Domagoj T]

Are you sure your code is correct?

[Jan Audio]

I dont know, what do you mean ?

There is no further info :
https://www.ebay.com/itm/293687768027?hash=item446127b3db:g:V24AAOSwtbpeg2vb

[Domagoj T]

You are using some software to monitor the encoder. Are you sure the software is correct?
Show us the code.

[madires]

If "EC11" refers to being compatible with ALPS EC11 series then the rotary encoders should have two Gray code steps per detent. However, most cheap rotary encoders have four Gray code steps (complete Gray code sequence) per detent. You can check that also with an inexpensive USB-based logic analyzer, if you don't have a multi-channel scope.

[wizard69]

Look up the manufacture and part number on google and down load the data sheet.    Right now you have people guessing at what might be the encoders behavior which is not all that useful if the actual device family is not known.

If the encoder doesn't have suitable markings nor the packaging, then I'd call this a lesson learned.   Most likely it isn't the encoder you think it is.

I have these from ebay :
50PCS Rotary encoder code switch EC11 audio digital potentiometer with switch 5p

ITEM PRICE:
US $22.20

Glad i dont have 100.

What does that EC11 means then ?
Same as the bourns ?

[rhodges]

I have some ALPS rotary encoders, and here are my notes from my library:

Code: [Select]

The ALPS rotary encoder switch has 30 detent positions, each one spaced 12
degrees apart. The three (encoder) pins are A (left), Common, B (right).
Pins A and B should be pulled up to Vcc; 10K resistors are recommended to
keep current under 1mA. Here, the input pins have internal pull-ups of
about 40K.

Both A and B are stable at detent position, and both A and B will have
the same output. When the encoder is rotated clockwise, B will change
first, then A. For counterclockwise, A will change first, then B.

Instead of using Interrupt On Change, poll at a rate often enough to
catch the fastest transitions. One full revolution in half a second
might be a good starting point, which gives 60 pin changes per second,
or one every 16 milliseconds. Oversampling by 4 would give one poll
every 4 milliseconds, which is probably already a timer interrupt.

0.      Read pins A and B, save starting status.

Polling procedure:

1.      Are pins A and B the same?
        NO: Which changed from saved status? Set direction flag. Exit.
        YES: Continue to 2.

2.      Are A and B equal to last saved status?
        YES: Encoder at same detent position. Ignore. Exit.
        NO:  Save new status. Eval direction flag and indicate rotation.
You can see the source code here (it's pretty short):
https://github.com/unfrozen/stm8_libs/blob/master/lib_rotary.c

[wizard69]

I don't have any use for the code right now but I must say I like you commenting style and easy to read code.

You can see the source code here (it's pretty short):
https://github.com/unfrozen/stm8_libs/blob/master/lib_rotary.c

[Nusa]

I dont know, what do you mean ?

There is no further info :
https://www.ebay.com/itm/293687768027?hash=item446127b3db:g:V24AAOSwtbpeg2vb

I followed your link. What passes for a datasheet is in the 2nd image (I could read it in full screen or zoom modes). With a blowup of the mechanics in the 3rd image.

You can always rig up a test circuit with led's for both outputs. If you turn the shaft very slowly, you should be able to see the expected waveform. If you turn it faster, you should be able to see them both blinking.

[rhodges]

I can send you some ALPS encoders. Send me PM if interested.

[Jan Audio]

LOL, thanks.

I will find out, i go solder one of these green/blue ones to a working project.
The total blue ones i always had are good.

[Jan Audio]

Show us the code.

https://www.eevblog.com/forum/microcontrollers/how-to-properly-code-rotary-encoder/msg2875434/#msg2875434

[tszaboo]

Well, i have my code in the main loop, no interrupts.

If you use a library, you have to call the rotary encoder handler quite often.
Really often.
If you have a display or handle anything slightly demanding, like writing to serial port, then you might already fail to call the handler often enough. Then it skips or it wont work properly. Also, pull up resistors.

[Jan Audio]

Maybe i should try interrupts then.

Yes i have a display, my other project also works.
Need to order those blue ones i think.

btw : the display dont halt the code, it polls the timer, even for each enable state.

[MarkF]

Maybe i should try interrupts then.

Yes i have a display, my other project also works.
Need to order those blue ones i think.

Interrupts are for doing a fixed sample rate.
(i.e. NOT Interrupt-On-Change of the pins as I've seen so many do.)
Interrupt-On-Change can overload your processor.

I've found that you pretty much need to sample at 500Hz or faster to avoid missing pulses.

[Jan Audio]

I have to measure a pin with my multimeter to see if i am around that 500KHz.

[madires]

I've found that you pretty much need to sample at 500Hz or faster to avoid missing pulses.

And I'd recommend to design your algorithm to be able to cope with bad Gray code steps because the cheap encoders don't create nice and clean pulses as good encoders do. There can be a huge difference in timing and bouncing behavior.

[xavier60]

The transitions can be very close together so I poll at 1mS.
On each change, I Left shift the A and B bits into a 6 bit register then test for 0x12 or 0x21 for up/down.
I use RC filtering and apply a drop of PAO oil to the encoder to stop it from becoming scratchy with time.
It also helps for the input ports to be anything but TTL level.
Putting capacitors directly across the encoder contacts without  series resistors can cause discharge spikes resulting in miscounts.

[Jan Audio]

I sample at 35KHz.
Cant have 500KHz in a 8-bit PIC.

[tszaboo]

I sample at 35KHz.
Cant have 500KHz in a 8-bit PIC.

It was 500 Hz, not KHZ.
35KHz should be enough to catch all pulses IMHO. I mean with a really good confidence, with not superhuman scrolling speeds.
You get usually surprises, when using Arduino with some badly designed blocking libraries.

[Jan Audio]

Ah ok thanks, i readed it to fast.
All my code is custom without blocking, fastest non-asm code with free mode in the west.

[szszoke]

I am using rotary encoders for my project that always give pulses when it is being turned.

I debounce the signal with a couple of 10k resistors and 100nF capacitors.

Both pins (let's call them A and B) pulse when the encoder is moved by one detent.

Depending on the direction, either A or B will be pulsed first.

Because of this behavior, I can essentially use one pin as a "clock" which would trigger a pin change interrupt, and inside that interrupt I can read the state of the other pin. The state of that other pin will give me the direction.

I tried the polling method as well but it kept not working and kept missing pulses when I turned my encoder faster.

I am not missing steps this way, and the hardware debouncing ensures that I have clean pulses.

If nothing else works, maybe you can give this a try.

[tooki]

personally I don't know any encoders which don't do gray code output, so I'm a bit surprised that you struggle with it now.
never mind whether I used magnetic, optical or mechanical encoders, they all worked the same way, with same code on mcu side
most of my projects run with those cheap china encoders, never had any unexpected behaviour with them

If "EC11" refers to being compatible with ALPS EC11 series then the rotary encoders should have two Gray code steps per detent. However, most cheap rotary encoders have four Gray code steps (complete Gray code sequence) per detent. You can check that also with an inexpensive USB-based logic analyzer, if you don't have a multi-channel scope.

Incremental encoders like EC11 are not Gray code, but quadrature. Actual Gray code is used in absolute encoders.

[jesuscf]

personally I don't know any encoders which don't do gray code output, so I'm a bit surprised that you struggle with it now.
never mind whether I used magnetic, optical or mechanical encoders, they all worked the same way, with same code on mcu side
most of my projects run with those cheap china encoders, never had any unexpected behaviour with them

If "EC11" refers to being compatible with ALPS EC11 series then the rotary encoders should have two Gray code steps per detent. However, most cheap rotary encoders have four Gray code steps (complete Gray code sequence) per detent. You can check that also with an inexpensive USB-based logic analyzer, if you don't have a multi-channel scope.

Incremental encoders like EC11 are not Gray code, but quadrature. Actual Gray code is used in absolute encoders.

Quadrature encoders produce 2-bit Gray code:

00 -> 01 -> 11 -> 10 -> 00 etc.

[xavier60]

All cheap mechanical rotary encoders that I have purchased on ebay have been the type where A and B momentarily turn on between dents, always off at each dent.
This sort of thing, https://www.ebay.com.au/itm/311947024355?hash=item48a17dd7e3:g:wbAAAOSw7ZlZoZDq

[xavier60]

After a lot of searching, this is the only mention I have found about the 2 types, https://forum.arduino.cc/t/strange-rotary-encoder-problem/483892/4

[madires]

All cheap mechanical rotary encoders that I have purchased on ebay have been the type where A and B momentarily turn on between dents, always off at each dent.

Those create four Gray code steps per detent (see the diagram posted by jesuscf). The number of steps is important for encoders with detents because you want to align the change of some value with the detents for proper user feedback. For encoders without detents, which turn freely, it's not that important.

[xavier60]

Many timing diagrams don't show the dent positions, causing ambiguity.
This example shows the 2 dent positions, https://tech.alpsalpine.com/prod/e/html/encoder/incremental/ec11/ec11_common.html

[Jan Audio]

Ok they do work.
I was tired of this problematic hobby and quitted a while.
They are ok i still need to find some problem, no impulses on 1 line, cable is good.

[rstofer]

Maybe i should try interrupts then.

Yes i have a display, my other project also works.
Need to order those blue ones i think.

Interrupts are for doing a fixed sample rate.
(i.e. NOT Interrupt-On-Change of the pins as I've seen so many do.)
Interrupt-On-Change can overload your processor.

I've found that you pretty much need to sample at 500Hz or faster to avoid missing pulses.

Interrupt on change is very fast when implemented as a state machine and table driven.  It also takes care of bouncing (generally) by looking only for expected edges for the interrupt on change.

Here is some very credible code that is nearly identical to what I wrote years ago.

https://github.com/buxtronix/arduino/blob/master/libraries/Rotary/Rotary.cpp

Sampling burns a lot of CPU cycles for nothing when the encoder isn't being used and the sample rate needs to be quite high.

With interrupt on change, no cycles are used unless the encoder is actually changing positions.  It's pretty clear that if we just did an interrupt on change for the falling edge of a signal, we need to change the interrupt direction to interrupt on rising edge.

Google for 'rotary encoder interrupt driven state table'

[rstofer]

I found my code written for some variant of the ATmega128.  This was written for wheel encoders on a small robot so the signals are changing pretty fast.  It also counts +4 for a complete transition.  It counts each transition as + or - 1 depending on direction.  This will need to be rethought for panel encoders but the idea is right.  The interrupt handlers are pretty short!

Code: [Select]

#include <avr/io.h>
#include <avr/interrupt.h>

#include <stdio.h>
#include <ctype.h>

#include "defines.h"

volatile int8_t  RightWheelState = 0;
volatile int32_t RightWheelCount = 0;
volatile int8_t  LeftWheelState  = 0;
volatile int32_t LeftWheelCount  = 0;

volatile uint8_t urx;
volatile uint8_t urx_recv;

/* Quadrature Encoder Scheme
 *
 * There are two pairs of quadrature signals, one for each wheel.
 *      The right wheel is on EXINT4 (PE4) and EXINT5 (PE5)
 *      The left  wheel is on EXINT6 (PE6) and EXINT7 (PE7)
 *      Each encoder has two outputs A & B.  For convenience, A is considered the MSB
 * while B is considered the LSB.
 */

const int32_t EncoderB[] = {+1,-1,-1,+1};
const int32_t EncoderA[] = {-1,+1,+1,-1};

SIGNAL(SIG_INTERRUPT4) // encoder B for right wheel
{
EICRB           ^= 0x01; // toggle the edge bit
RightWheelState ^= 0x01;
RightWheelCount += EncoderB[RightWheelState];
}

SIGNAL(SIG_INTERRUPT5) // encoder A for right wheel
{
EICRB         ^= 0x04;
RightWheelState ^= 0x02;
RightWheelCount += EncoderA[RightWheelState];
}

SIGNAL(SIG_INTERRUPT6) // encoder B for left wheel
{
EICRB          ^= 0x10;
LeftWheelState ^= 0x01;
LeftWheelCount += EncoderB[LeftWheelState];
}

SIGNAL(SIG_INTERRUPT7) // encoder A for left wheel
{
EICRB          ^= 0x40;
LeftWheelState ^= 0x02;
LeftWheelCount += EncoderA[LeftWheelState];
}

void IOInit(void)
{
UBRR0H = 0;
UBRR0L = BAUD;
UCSR0B = _BV(RXEN) | _BV(TXEN) | _BV(RXCIE);
}

static int uart_putchar(char c, FILE * stream)
{
if (c == '\n')
uart_putchar('\r', stream);
while (! (UCSR0A & _BV(UDRE)))
;
UDR0 = c;
return c;
}

SIGNAL(SIG_UART0_RECV)
{
uint8_t s;

s = UCSR0A;
urx = UDR0;
if (bit_is_clear(s, FE))
urx_recv = 1;
}

void QuadInit(void)
{
LeftWheelState  = (PORTE & 0xC0) >> 6;
RightWheelState = (PORTE & 0x30) >> 4;
EICRB = 0xff;                           // enable rising edge triggering on INT4..7
EICRB ^= (LeftWheelState  & 0x02) << 5; // if a signal is already set
EICRB ^= (LeftWheelState  & 0x01) << 4; // set the interrupt to falling edge
EICRB ^= (RightWheelState & 0x02) << 1;
EICRB ^= (RightWheelState & 0x01);
EIMSK = 0xf0;                           // enable these 4 interrupts
}

int main(void)
{
IOInit();
QuadInit();
sei();

fdevopen(uart_putchar, NULL);
printf("Hello World\n");

while (1) {
printf("LWS =%2d LWC =%6ld RWS =%2d RWC =%6ld\n",
LeftWheelState, LeftWheelCount, RightWheelState, RightWheelCount);
}
}
[/font]

[Old Printer]

Post a scope trace.

I have a single channel analog scope.
Waiting for a modern scope to come out anytime soon with better specs.

I assume you are kidding??