1. Home
  2. General Robotics Forum
  3. Quadrature Decoder Question

Quadrature Decoder Question

Hi guys,

The output from a Rotary Shaft Encoder(Quadrature Encoder) are given as inputs to a Quadrature decoder which basically gives out a UP/DOWN signal and a pulse count signal(which gives the total number of counts).

My questins are

a) A simple decoder using two D Flip-Flops for decoding the up/down signal and a XOR gate for the pulse count would be easy.But I read somewhere(don't remember where) that the above mentioned circuit will miss pulses when the direction is changed.How can that be eliminated.Are there any other ways of decoding digital quadrature signals.I can use PAL/GAL etc to implement the logic.

b) The Geckodrive series of Servo Controllers takes Step and Direction signals as inputs and controls the servo's using quadrature encoder feedback.The output from the quadrature decoder is given to an UP/DOWN Counter.The STEP and Direction signals are given to another UP/DOWN Counter.What I don't understand is that a Parallel Adder is used to add the above two counters and routed to a D/A counter from where PID control action starts.What exactly is happening at the Adder and it's ouput.I mean what are we getting by adding those both counters indefinetly.since the STEP & Direction signals are inputs(also set points) and Decoded Quadrature signals are also inputs(present position,measurement points).If you want to see the actual block diagram you can get it at

formatting link
see last but one page.Also How can position,velocity and acceleration be interpredted from a Quadrature Encoder or from a Quadrature Decoder.

Thank You, prizark.

Reply to
prizark
Loading thread data ...

Quadrature is straightforward. Think of a circle with four quadrants, and a pointer that can rotate around the circle. One output is on when the pointer is in the "upper half", and one output is on when the pointer is in the "right half". From this you can reliably obtain position, and there's no need for a clock.

The reason this is reliable is because only one bit changes at a time. If you're near an edge, the meaning is unambiguous. Consider the case where the pointer is pointing "straight up". The "upper half" bit is on solidly, and the "right half" bit may jitter on and off. So there's ambiguity over which of the two top quadrants you're in, but that jitter will never result in an error of more than one count.

There are standard circuits for connecting quadrature encoders to counters, and you can find them with Google.

That's why encoders have more counts per rev than you'd think would be necessary. Velocity is usually obtained by differencing position, and acceleration (which you probably don't need) is obtained by differencing velocity. The more counts you have per rev, the lower the roundoff jitter in velocity.

There are also some interesting options for using phase locked loops to compute velocity when your encoder doesn't have enough encoder counts, but that's more than we have time for today.

John Nagle Team Overbot

Reply to
John Nagle
[snip...snip...]

One option would be a dedicated decoder like this:

formatting link
It's about US$14 qty 1 but it lets you get on with worrying about what to *do* with the data instead of fiddling with a roll-yer-own. OTOH, of course, sometimes the fiddling is the whole point...

Reply to
Rich Webb

---------------- If the pulses are sufficiently close, ANY decoder will miss them, just ignore that. Use a routine to center your driver on a dither cycle so that it has a sensor to base numeric references off of, or else use an absolute encoder.

----------------- I'd need to see your schem, but generally if you can get the numbers you can control the addition in program code, and regard the counters as only relative beyond a certain bracketed delay time.

-Steve

Reply to
R. Steve Walz

iirc there is no simple way to decode quadrature signals using asynchronous logic, although, as you said, there are plenty of ways to "almost" do it correctly. doing it with clocked logic, however, is trivial. also, to second whoever said it, i have used the ls7266 before and been satisfied with it. its 1-qty price is probably less than your 1-qty price of figuring out how to do it by hand.

-chris.

Reply to
Edward C. Kern

Probably the simplest way (in a GAL or FPGA) is a synchrounous state machine running at say 4 times the maximum count rate.

Perhaps the adder is really a subtractor, comparing the desired position (from the up/down counter) and the real position (from the encoder counter), generating the position error which is the main input to the PID loop. The PID loop also needs velocity whch can be obtained from the difference in positions at discrete time intervals.

This velocity calculation gets 'lumpy' at low velocities so fancier controllers may use digital filtering, measure period between encoder edges etc etc at low speeds)

Peter Wallace

Reply to
Peter Wallace

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.