Rotary incremental encoders

[akis]

I am trying to understand how these work

for example http://www.adafruit.com/datasheets/pec11.pdf

As I understand it there are 3 pins: A, B and GND. As you turn the knob it clicks. With each click the device closes A, closely followed by B and then opens A and then opens B, and it does that with each click. If then you had pulled A and B high, for every click it would pull A low, then B low, then A high and finally B high. If you turned it CCW, then it would go backwards, ie it would pull B low, then A low, then B high and finally A high.

So to interface these with a MCU you'd have to be reading digitally A and B continuously so you'd need 2 digital inputs on the MCU. But you'd need to be reading all the time because you might miss a turn/click. Assuming the MCU does not have interrupts.

Have I got it right?

[madires]

Yes, the rotary encoder creates a Gray code output and you can determine the direction by observing the changes. If you're using the polling method to read the encoder, polling it every 5ms should be fine. It's even good enough to support a velocity factor (how fast or slow the encoder is turned). The "clicks" are called detents and a single detent could be a single Gray code step or more. That's based on how the encoder is designed. Some cheap encoders got the detent just at the position where the A and B change, i.e. A and B could change back and forward several times.

[LaurenceW]

You're basically right, Akis, yes.  As per the little table in the data sheet, if you see "A" go low, and then before anything else changes "B" also goes low, you know the shaft has been turned clockwise. But if "B" goes low and before anything else changes "A" goes low, then the shaft has been rotated counterclockwise.

Ideally, you might do this with interupts (or "interupt on change" if your processor has it). This way, you can also time the gap between successive rotations, and set your software to do speed-dependant changes - i.e., the faster you spin the knob, the much faster you increment or decrement the value.

You could do it by polling every few ms if you don't want to use interupts, but you risk missing the occasional pusle, which will make the "action" of the knob feel a bit hit-and-miss.

I scan both bits frequently, and compare to the previous scan. Both bits can only ever be 00, 01, 10 or 11. Compare with previous value and determine directions.  Use 4K7 pull-up resistors and 0.1 uf glitch-catching caps to ground, to kill switch bounce. Job done!

[electr_peter]

Yes, you described rotary encoders very well.

MCU can read A/B signal via simple digital read or an interrupt. Keep in mind that these mechanical encoders can switch bounce significantly - add some analog filtering (preferable - pull up, cap+resistor for low pass, Schmitt trigger) or digital filter. Also, don't expect to quickly turn the knob, say 10 times CW and 10 times CCW, and get to the original position with 100% probability.

Polarity is difficult to get right from the first go. Another point - MCU code must be able to start with encoder in the middle position between indents (when A is on and B is off).

Bonus tip - you don't actually need to read positions of A and B signals at once - it is enough to keep track of A and B states (and stick to possible A/B combinations) and update to possible states only (so both A and B do not change at the same time).
Read A - if A changed, then update A state. Read B ...
Read A - if A did not change, continue.         Read B ...

[madires]

Ideally, you might do this with interupts (or "interupt on change" if your processor has it). This way, you can also time the gap between successive rotations, and set your software to do speed-dependant changes - i.e., the faster you spin the knob, the much faster you increment or decrement the value.

IMHO, using the interrupt method is ok for high quality encoders like Alps, but not for cheap crap. The cheap encoder might have the detent just at the position where A and B change and that causes several fast changes without intent. When using interrupts such an encoder could cause a lot of fun with a an interrupt storm.

[andrija]

Ideally, you might do this with interupts (or "interupt on change" if your processor has it). This way, you can also time the gap between successive rotations, and set your software to do speed-dependant changes - i.e., the faster you spin the knob, the much faster you increment or decrement the value.

IMHO, using the interrupt method is ok for high quality encoders like Alps, but not for cheap crap. The cheap encoder might have the detent just at the position where A and B change and that causes several fast changes without intent. When using interrupts such an encoder could cause a lot of fun with a an interrupt storm.

Even the Alps encoder might no do it clean like you described. I implemented rotary volume control code in assembly on a PIC for my DAC and some encoders with detents also have a position in between two detents.

[madires]

Even the Alps encoder might no do it clean like you described. I implemented rotary volume control code in assembly on a PIC for my DAC and some encoders with detents also have a position in between two detents.

Are you talking about two Gray code steps for one detent (like Alps' EC11 series) or about unstable A/B at the detent?

[andrija]

Two codes. One right at the detent and other as you move shaft a bit farther to the next detent but not trigger the next detent. Then once you get the second code, you can move the shaft back and get the code to change back to what it was on the first detent. These in between codes are pretty non-deterministic in when exactly they happen since they are not at the detent but I don't know how much instability and bouncing there is, if any. I don't think my code had any debouncing at all and it always worked fine.

[electr_peter]

Even the Alps encoder might no do it clean like you described. I implemented rotary volume control code in assembly on a PIC for my DAC and some encoders with detents also have a position in between two detents.

I think you mean that encoder could stop in intermediate position ("on detent"). That is, encode goes 00, 01, 11, 10, 00, ... and stops on 01/11/01 position. This can be a problem if your code does not account for it. As I wrote earlier,

Another point - MCU code must be able to start with encoder in the middle position between indents (when A is on and B is off).

Problem with these mechanical encoders is that all switching action happens only around detent (all 4 transitions happens on 1 detent - 00, detent starts, 01,11,10,00, detent ends). You have 4 events for 1 detent. This makes calculation slightly more tricky in my opinion and creates intermediate states (01/11/10) code must recognise.

[madires]

Two codes. One right at the detent and other as you move shaft a bit farther to the next detent but not trigger the next detent. Then once you get the second code, you can move the shaft back and get the code to change back to what it was on the first detent. These in between codes are pretty non-deterministic in when exactly they happen since they are not at the detent but I don't know how much instability and bouncing there is, if any. I don't think my code had any debouncing at all and it always worked fine.

I see. The trick is to track the steps in the same direction. If you got two steps clockwise consider it a successful turn clockwise and reset the step counter to 0. The third step clockwise, going a little bit further, is just a single step and not considered a successful turn. The next step is counterclockwise (back to the last detent), and since it's the other direction the step counter is reset to 1 again. Of course you have to remember the direction of the last step.

[madires]

Maybe some code helps (for ATmega):

Code: [Select]

/* rotary encoder */
typedef struct
{
  uint8_t           History;       /* last AB status */
  uint8_t           Dir;           /* turn direction */
  uint8_t           Pulses;        /* number of pulses */
  uint8_t           Velocity;      /* turning velocity */
} RotaryEncoder_Type;

RotaryEncoder_Type        Enc;             /* rotary encoder */

#define ENCODER_PULSES   2              /* number of pulses per detent */
#define DIR_NONE         0b00000000     /* no turn or error */
#define DIR_RIGHT        0b00000001     /* turned to the right */
#define DIR_LEFT         0b00000010     /* turned to the left */

/*
 *  read rotary encoder
 *
 *  returns user action:
 *  - DIR_NONE for no turn or invalid signal
 *  - DIR_RIGHT for right/clockwise turn
 *  - DIR_LEFT for left/counter-clockwise turn
 */

uint8_t ReadEncoder(void)
{
  uint8_t           Action = DIR_NONE;       /* return value */
  uint8_t           Temp;                    /* temporary value */
  uint8_t           AB = 0;                  /* new AB state */
  uint8_t           Old_AB;                  /* old AB state */


  /* set encoder's A & B pins to input */
  Old_AB = CONTROL_DDR;                 /* save current settings */
  CONTROL_DDR &= ~(1 << ENCODER_A);     /* A signal pin */
  CONTROL_DDR &= ~(1 << ENCODER_B);     /* B signal pin */
  wait500us();                          /* settle time */

  /* get A & B signals */
  Temp = CONTROL_PIN;
  if (Temp & (1 << ENCODER_A)) AB = 0b00000010;
  if (Temp & (1 << ENCODER_B)) AB |= 0b00000001;

  /* restore port/pin settings */
  CONTROL_DDR = Old_AB;                 /* restore old settings */

  /* update state history */
  if (Enc.Dir == (DIR_RIGHT | DIR_LEFT))     /* first scan */
  {
    Enc.History = AB;                   /* set as last state */
    Enc.Dir = DIR_NONE;                 /* reset direction */
  }


  Old_AB = Enc.History;                 /* save last state */
  Enc.History = AB;                     /* and save new state */

  /* process signals */
  if (Old_AB != AB)        /* signals changed */
  {
    /* check if only one bit has changed (gray code) */
    Temp = AB ^ Old_AB;                 /* get bit difference */
    if (!(Temp & 0b00000001)) Temp >>= 1;
    if (Temp == 1)                      /* valid change */
    {
      /* determine direction */
      /* gray code: 00 01 11 10 */
      Temp = 0b10001101;                /* expected values for a right turn */
      Temp >>= (Old_AB * 2);            /* get expected value by shifting */
      Temp &= 0b00000011;               /* select value */
      if (Temp == AB)                   /* value matches */
        Temp = DIR_RIGHT;               /* turn to the right */
      else                              /* value mismatches */
        Temp = DIR_LEFT;                /* turn to the left */

      /* step/detent logic */
      Enc.Pulses++;                     /* got a new pulse */
      if (Temp != Enc.Dir)              /* direction has changed */
      {     
        Enc.Pulses = 1;                 /* first pulse for new direction */
      }
      if (Enc.Pulses >= ENCODER_PULSES) /* reached step */
      {
        Enc.Pulses = 0;                 /* reset pulses */
        Action = Temp;                  /* signal valid step */
      }

      Enc.Dir = Temp;         /* update direction */
    }
    else                                /* invalid change */
    {
      Enc.Dir = DIR_RIGHT | DIR_LEFT;   /* trigger reset of history */
    }
  }

  return Action;
}


That function is called every 5ms by another function which has a counter to determine the turning velocity.

BTW, the code is from the Transistortester's m-firmware.

[madires]

The way I understood it is that you detect a change in one channel (A or B) either by interupt or polling. Then you read the other channel. If it is low you are going in one direction. If it is high you are going in the other direction.

Basically you just need to detect which signal (A or B) changes. The magic of the Gray code is that only one bit changes from step to step. But you can also read both signals at the same time. And it's a good idea to detect code violations.

[akis]

After reading all comments, just some random thoughts.

If the encoder has say 24 positions, and you can turn it max, say, 360 degrees in 0.5 seconds, that means 48 detents per second. Each detent has 4 transitions which you must read ie 00, 01, 11, 10, 00, so you will have to poll 48 * 5 reads per second = 240 reads per second. But to make sure you are catching them in time, since there are no interrupts to tell you precisely when a state actually became a state, you 'd need to be reading at least twice as many times per second. That means 480 reads per second on both A and B pins, therefore every 2ms give or take.

In terms of high level algorithm you can read successive states into an array/queue and then process in a FIFO manner trying to extract correct sequences, disregarding anything invalid. So one part of the code fills the queue up with successive states, and some other part of the code tries to extract complete "messages" out the queue (simply by recognising 2 possible sequences). If your queue starts in the middle of a sequence you can throw it out. This is almost precisely the same way we used to read bytes coming down the sockets and putting them together into "messages" from the other side.

[akis]

Some cheap encoders got the detent just at the position where the A and B change, i.e. A and B could change back and forward several times.

That means that even if the analogue circuitry is good, the cheap encoder will still "bounce" A and B and if I am reading too fast I will read garbage?

MCU can read A/B signal via simple digital read or an interrupt. Keep in mind that these mechanical encoders can switch bounce significantly - add some analog filtering (preferable - pull up, cap+resistor for low pass, Schmitt trigger) or digital filter. Also, don't expect to quickly turn the knob, say 10 times CW and 10 times CCW, and get to the original position with 100% probability.

So I need : pullup resistor, followed by series resistor and a capacitor to ground to form a low pass filter? Or can I just place a capacitor to ground and not need the series resistor?

[akis]

I wonder isn't there a chip to couple with the encoder and do all the reading and buffering and then simply give you the "messages" via say a serial interface? So then the only thing you have to do is "read next" and not have to tie down the MCU ?

[electr_peter]

If the encoder has say 24 positions, and you can turn it max, say, 360 degrees in 0.5 seconds, that means 48 detents per second. Each detent has 4 transitions which you must read ie 00, 01, 11, 10, 00, so you will have to poll 48 * 5 reads per second = 240 reads per second. But to make sure you are catching them in time, since there are no interrupts to tell you precisely when a state actually became a state, you 'd need to be reading at least twice as many times per second. That means 480 reads per second on both A and B pins, therefore every 2ms give or take.

Take into account that sequence 00,01,11,10,00 is not evenly spaced (if knob is turned at the same speed). Depends on the encoder, of course.

In terms of high level algorithm you can read successive states into an array/queue and then process in a FIFO manner trying to extract correct sequences, disregarding anything invalid. So one part of the code fills the queue up with successive states, and some other part of the code tries to extract complete "messages" out the queue (simply by recognising 2 possible sequences). If your queue starts in the middle of a sequence you can throw it out. This is almost precisely the same way we used to read bytes coming down the sockets and putting them together into "messages" from the other side.

It will probably work OK.
I would suggest to keep track of current A/B states and update them sequentially - read A, update A; read B, update B. You check for proper state change and your states (A and B including) are always legal this way (legal, because all legal transitions change only A or B state, not both).

Problem with throwing out "illegal codes"(or reading A/B incorrectly) would be possibility of turning the knob one way, but getting result +1,+1,+1,-1,+1 (there should be no -1 if you turn in one direction).

I suggest to build a circuit and try out your approach and other approaches in practice. I presume you would use encoder for UI? Then hands on testing is necessary.

[rs20]

Just a note -- people seem to be panicking about rotary encoders that have unstable outputs when resting on the detents. The ONLY time this is an issue is when your code gets bogged down by an interrupt storm. It may be unstable output, but it's unstable output that alternates between exactly two grey code states: in other words, no problem at all in terms of having the MCU keep track of where the encoder is. If the MCU is polling and misses any amount of random junk, it'll still just read the next valid value. Rotary encoders only break when the MCU misses two or more motions in the SAME direction, which this unstableness will never produce. The only problem is that your software will see the knob wobbling between those fixed two values; you just need to mask out/ignore the unstable LSB and you're fine. For newbies, though, it might be easier to debug with nice stable encoders.

[SL4P]

Capacitor - and you may like to add a small debounce period in the ISR to ignore changes faster than your max permitted pulse rate.  e.g. reset a countdown timer and ignore state changes before that zeroes out

[madires]

Some cheap encoders got the detent just at the position where the A and B change, i.e. A and B could change back and forward several times.

That means that even if the analogue circuitry is good, the cheap encoder will still "bounce" A and B and if I am reading too fast I will read garbage?

Let's take an example of an encoder with one step per detent. A good encoder would make A/B switch between two adjacent detents. First the A/B signals change, then the detent "clicks". That way you got a stable A/B signal (stable in the meaning of that A/B won't change if you wiggle the knob at the detent a little bit). Some cheap encoders got the A/B switching and the detent at the same position. Since there's some margin for the detent, A/B could change easily several times. That could be caused by you, reaching the detent, overshooting a little bit and turning back until the encoder snaps into the detent's position. Or by touching, moving or hitting the device. Of course you also got the beloved bouncing of the switching contacts

[rs20]

Some cheap encoders got the detent just at the position where the A and B change, i.e. A and B could change back and forward several times.

That means that even if the analogue circuitry is good, the cheap encoder will still "bounce" A and B and if I am reading too fast I will read garbage?

Let's take an example of an encoder with one step per detent. A good encoder would make A/B switch between two adjacent detents. First the A/B signals change, then the detent "clicks". That way you got a stable A/B signal (stable in the meaning of that A/B won't change if you wiggle the knob at the detent a little bit). Some cheap encoders got the A/B switching and the detent at the same position. Since there's some margin for the detent, A/B could change easily several times. That could be caused by you, reaching the detent, overshooting a little bit and turning back until the encoder snaps into the detent's position. Or by touching, moving or hitting the device. Of course you also got the beloved bouncing of the switching contacts

But you won't "read garbage" because your software will resolve the data into perfectly legitimate positions, with just a bit of uncertainty in the last bit that never accrues or gets out of hand. This is easily dealt with; in the simplest case, just mask out the last bit and you'll still unambiguously know which detent you're sitting in. Unless there's only one gray code per detent, in which case it becomes a big issue.

[madires]

Basically you just need to detect which signal (A or B) changes. The magic of the Gray code is that only one bit changes from step to step. But you can also read both signals at the same time. And it's a good idea to detect code violations.

I'm not actually speaking from experience here. I also don't follow what you are referring to as code violations. Do you mean bugs? Or incorrect outputs from the encoder?

Incorrect outputs from the encoder and signal glitches. The output is a Gray code, so only A or B may change, but not both.

I was just looking at the linked datasheet and the output waveforms. It seemed to me that since both signals (A and B) change but out of phase. So if in the clockwise (CW) direction the A signal transitions H to L the B signal is always H. Alternatively in the Counter clockwise (CCW) direction if the A signal transitions H to L the B signal is always L. So if you detect an A signal transition you simply need to immediately  read the B signal to find the direction. Or vice-versa.

Yes, that's one of the classic methods. But you have to take the delay between A and B, and the bouncing into account for reading B. The delay also varies with the speed of turning.

I also don't see what the dashed D line in the waveform diagram is for.

It's the postion of the detent. In this case it's a proper encoder switching A/B between detents.

[madires]

I wonder isn't there a chip to couple with the encoder and do all the reading and buffering and then simply give you the "messages" via say a serial interface? So then the only thing you have to do is "read next" and not have to tie down the MCU ?

Use a dedicated MCU for the rotary encoders

[madires]

But you won't "read garbage" because your software will resolve the data into perfectly legitimate positions, with just a bit of uncertainty in the last bit that never accrues or gets out of hand. This is easily dealt with; in the simplest case, just mask out the last bit and you'll still unambiguously know which detent you're sitting in. Unless there's only one gray code per detent, in which case it becomes a big issue.

And what do we learn from this? If you buy cheap encoders get the type with two code steps per detent.

[rs20]

Just to hammer my point home:

And what do we learn from this? If you buy cheap encoders get the type with (rs20 adds: at least) two code steps per detent.

Fully agree. Do cheap decoders with only one code step per detent AND crappy detent position actually exist though?? Datasheet? I've only ever seen encoders with two or four code steps per detent personally. I think it's worth being crystal clear that you're only going to end up in trouble if you have the perfect storm of both crappy detents AND single code steps per detent.

EDIT: Fixed broken image link.

[SL4P]

Forget the detent. 
It's only there to make you feel like you're doing something, and to stop the shaft rotating under its own steam (and vibration).

Use edge detection on the 'known' good pin (A/B) - then determine which phase the other (B/A) pin is in. Count up or down as needed.  Finished.

$0.30c 6/8 pin MPU to process if needed, or $0.00 - use an interrupt pin on your application MPU.