quadrature encoder

It isn't.

-- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Bahdges? We don't need no stinkin' bahdges! -- "The Treasure of Sierra Madre"

When do you want information from the encoder? What information do you *want*??

Homework?

It isn't always necessary, but paying attention to all the edges gives you a more robust system.

How do you want to do it? Does your preferred method give exactly correct readings if the encoder suddenly reverses, if it experiences switch bounce, or if it "camps" on one spot with one channel stuck in a state and the other constantly transitioning?

You can decode with one edge only. If you use both edges then the resolution of the system will double.

Walter..

You can decode with one edge only if you don't mind if the decoding is error prone and noise sensitive. There's just not complete information to take in all the cases unless you pay attention to both the rising and falling edges of both channels.

If you only care about speed and not direction, one edge on one channel may be sufficient.

Yes, but* only if the encoder is known to be turning, and if it's a technology (i.e. optical or magnetic) that doesn't bounce.

I've always been information starved, and have always used all the edges available to me -- which doesn't mean that the next project that comes down the pike won't work fine with a single edge on a single channel.

• I'm really not in a pissy mood today -- pedantic, maybe, but not pissy.

But paying attention to all edges doesn't necessarely mean you have to

Correct, and it's why I worded what I said the way I did.

It's far easier to make a little state machine (in either hardware or software) with a pair of binary states that runs at a sample rate guaranteed to catch every valid edge than it is to make a bit of hardware that actually derives it's clock edges from the edges of the incoming signals.

ay be sufficient.

A purist could argue, that for position, all edges should be used, (you can easily discard precision later) but for speed readings, only the same edges should be considered, as quadrature encoders are NOT guaranteed to have 50.00% duty cycles (or even 90.00' alignment).

-jg

Because if the encoder changes direction, you will clock on the wrong edge and slowly lose registration.

Try it for yourself as a paper exercise; keep changing direction over a very few steps and watch your position counter slowly drift!

And it doesn't have to be a deliberate change of direction, either. Torsional vibration when the encoder is sitting on one of the edges will cause a steady creep in one direction.

Let me try to phrase that a little better.

Let us suppose that you are operating bi-directionally, clocking from the rising edge, and the encoder is sitting over what would be your falling edge. Each vibration backwards will give you what appears to be a rising edge, causing a downwards count, but each vibration forward will not be registered because it is sitting on the falling edge which you are ignoring.

And therby hangs a tale! In a recent project I wa controlling a stepper motor with such an encoder and was losing accuracy for the reasons stated above!

The algorithm to avoid the problem comes from a much larger state machine than is normally used ... you have to consider what you are going to do if you receive two opposite transitions from the same input without there being a transition on the other input.

be sufficient.

Machine-tool grade encoders had damn well better be guaranteed to have accurate angular alignment.

be sufficient.

What do you reckon the accuracy of quadrature is?

Here's a typical Renishaw read head datasheet:

The only hint I see is a 4:1 "safety factor" on the counter clock frequency max.

be sufficient.

In this case I would imagine the accuracy would be determined more by the scale than the readhead.

But that's just a guess...

be sufficient.

Hi One problem to watch out for is to not feed an analog encoder output in to a Schmidt triggered buffer. The problem is the levels it switches at eats up most of the phase margin. I've seen a couple of mouse designs that were real flaky using a 74HC14 directly from the encoder. As things ( led ) age, the mouse begins to fail. You need to amplify the signal some first such that the rise and fall phase angles are sharper than the sine/cosine of the encoder. One could also use something like a comparator chip with less positive feedback than the 74HC14 uses. Dwight

Ah - finally, the correct answer! It's not necessary, or event desirable, to clock on one of the channels, but for an application where you care about long-term accuracy, it's *essential* to clock on both the rising and falling edges of the other channel. Magnum's explanation is exactly right!

That said, there are often times where I ignore this. Specifically, when using a rotary encoder knob as a user interface input device (most car radio volume controls are this way, now), an occasional "lost step" isn't really too important, and the programming to capture the knob data is usually greatly simplified. In fact, most processors can only be configured to interrupt on a transition in one direction, some external logic is needed to get both transition directions. Polling the input is another alternative, usually not a very good one...

-- Mark Moulding