3
\$\begingroup\$

I have this encoder. But I'm having extreme difficulty understand how these encoders work.

I tried to google but still cannot picture in my mind how they really work. I spend two days for research but no luck.

Here are my questions:

1-) What I read is that when we rotate the knob the output A and B should output pulses with 90 degree phase difference and this phase difference is only to determine the rotation direction:

enter image description here

But how does output from A produce this shifted wave form? I mean what happens internally/mechanically so that even we switch one click there becomes these waveform. This is very confusing to grasp. Btw when I wired up in scope I dont see 90 degree phase differences between A and B when rotating. Sometimes it is very very little phase difference. Do all mechanical rotary encoders supposed to work same way?

2-) Is only one of A or B used to measure the rotation angle? How is this waveform interpreted so that we can measure the angle rotated. Again I cannot picture the relation between pulse per revolution (ppr), and angle here.

3-) I'm also confused with term gray code. Is that something unrelated to these type of encoders?

\$\endgroup\$
  • 3
    \$\begingroup\$ There are two sets of radial lines etched on the rotating disc- A and B. The A and B lines are interleaved. The encoder needs to be rotated at constant speed to see the 90deg phase shift between phases on an oscilloscope. A D-type flip-flop is the best device for decoding the direction of rotation. Gray code is relevant to absolute encoders, not incremental encoders. \$\endgroup\$ – Chu Jan 17 '17 at 22:51
5
\$\begingroup\$

If you look at the ALPS datasheet for your part, you will see the following diagram:

enter image description here

Here, they show you a test circuit on the left side. You are supposed to be able to find that kind of thing in a datasheet. It's a small skill. But one you will need to develop. (You will also need to develop the skill required to find the datasheet in the first place, of course.)

Note that they include two resistors, attached to terminals A and B. These are "pull-up" resistors. On the right side, you can see that they specify (implied as a recommendation for you to consider) a value of \$5\:\textrm{k}\Omega\$. Also, you will notice that on the left side terminal C is grounded and that they show you an internal behavioral model of the device, showing two switches inside of the dashed-line rectangle there. Finally, their example shows a \$+5\:\textrm{V}\$ supply rail. This is almost certainly not a requirement. But taken together with the resistor values, it suggests that if you use a different rail voltage then you probably want approximately \$\frac{5\:\textrm{V}}{5\:\textrm{k}\Omega}\approx 1\:\textrm{mA}\$ as the current that these switches encounter during use. If you stay close to that approach, you will probably be fine. Taken together, this tells you pretty much how this thing is supposed to be designed for proper use and wired up.

It also includes, on the right, a few details about "chatter" and "bounce." You need to take notice of these, as well. In the middle, they show a "masking time" with hashed bands to emphasize these details. You need to either develop a hardware circuit or else do something in software (or both) to accommodate this transitioning behavior. Although there are some solid arguments for an external, analog hardware circuit before your software gets a chance to see anything, most designers would go cheap here and instead depend entirely on software sampling processed by a state machine or some other software method to get the job done without any additional external parts. (Zero added space, free is cheaper, no added long term or thermal drift to worry about, etc.)

If you don't know how to handle the chatter/bounce, you are going to be in a world of hurt already. But we've not yet discussed Gray code and it appears you don't know what that is, either. You should definitely check out the Wiki page on Gray codes. (The subject is actually much more interesting than the Wiki page even suggests, involving encryption, snake-in-the-box, coil-in-the-box, Hamiltonian walks, and error detection and correction just as starters -- you can make a life's work out of this area.)

There is a definitely good reason for choosing a Gray coding here. But you can read the Wiki and get most of that worked out on your own, I think.


In this case, though, it's probably a lot easier to just focus on the fact that this is a quadrature arrangement. With the circuit laid out as shown above, with those resistors, you should see two square waves that are offset from each other as shown in the diagram you included because that is how the internal "switches" are arranged to operate under rotation of the dial.

It's actually pretty nice because you can tell which direction the dial is turning. Just first use your eyes to move from left to right across your diagram and see the order in which the values change and then use your eyes to move in the opposite direction, from right to left, and see how those transitions are uniquely different.


The main thing for you to know is that you will need two resistors and a voltage source in order to finish the circuit around the rotary switch. You will also need to wire the A and B terminals over to your micro, as well. You will need debouncing software and you will need decoding software, as well. With all that in hand, you should be able to make some use of the switch.

One remaining problem you may have is that a human looking at the knob might imagine that it is pointing to the left (let's say) and that your software should already know this fact when it powers up. But without some kind of "home" pulse to examine (which would still require the operator to twirl the knob for you to see) or without an absolute encoding (which this doesn't provide), there isn't a way to be certain. All this device can do is provide you details about the fact that rotation is occurring and in which direction. It's a relative encoder, in other words, and not an absolute encoder. Whether or not that helps you? No idea. Depends on your application.

If interested, a particularly interesting area of absolute position Gray encoders is called Single Track Gray Code. I'm not sure who is commercially producing these, as a patent was issued in 1994 and if the patent is off it has only been a few years since. But the concept is interesting to read about, regardless.

\$\endgroup\$
3
\$\begingroup\$

Imagine (or draw) the face of a compass, North to the top.

Now imagine signal A is a North/South switch, A=1 is North, A=0 is South.
Similarly, B is an East/West switch, B=1 is East, B=0 is West.

Let's say both A and B are 1, so we are pointing NE. If A changes to 0, it goes to SE, clockwise. However, from the same starting point, if B changes to 0, it goes to NW, counter clockwise.

So ALL transitions are meaningful, both A and B transitions, and signify a quarter turn. But in which direction?

Whether a transition indicates an increment or a decrement in angle depends on the state of the other signal.

\$\endgroup\$
  • \$\begingroup\$ Transitions due to bouncing are not meaningful. \$\endgroup\$ – CL. Jan 18 '17 at 7:54
1
\$\begingroup\$

To answer out-of- order

2) No, you need a A and B together – otherwise, the designers wouldn't have both, would they?

3) Gray codes are a way to map values to binary symbols. In short, to get to a "neighbor value" from your current one, you only flip one bit. That makes sense in the context of encoders, but you'd simply need to read a better introduction to them if you want to understand that, and your introductions hasn't showed that yet. You might want to look at how Gray codes are constructed and extended. However, the gray code aspect is irrelevant at your level of understanding.

1) For your understanding, try the following

  1. Pick either A or B as "clock", the other as "data" signal.
  2. When you see a positive edge (ie. transition from low to high) on your clock signal, what is the value of your data signal when you go in one direction, what is the value of your data signal when you see the same transition when you go in the other direction?

Notice that the direction decides which edges are positive and which are negative edges of your clock signal.

\$\endgroup\$
  • \$\begingroup\$ " No, you need a A and B together " I thought they are both used determine the direction. If you write a code for angle increment or decrements part wouldn't you use only one of A or B? A and B monitored for direction determination but how about the amount of rotation? Isn't only A or B enough as an input to a uC? \$\endgroup\$ – atmnt Jan 17 '17 at 20:40
  • \$\begingroup\$ @user134429 I really don't know what you mean. My question answers your question 2). \$\endgroup\$ – Marcus Müller Jan 17 '17 at 20:52
  • 1
    \$\begingroup\$ @user134429 the way you determine the amount of rotation is simply to count the number of pulses on whichever pin you decide to call "data". If you don't care about direction, just count the pulses on one pin. If you do care, then count the pulses, and use the other pin to work out which way it's going. \$\endgroup\$ – Simon B Jan 17 '17 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.