Rotary encoder issues.

tosjduenfs

I recently purchased 2 (http://www.digikey.com/product-search/en?KeyWords=pec16-4120f-n0012-nd&WT.z_header=search_go) of these encoders for a project but for some reason I cannot get them to work correctly. I wired them per the data sheet and grounded the case. When I try to read the output it will increase in multiples or not increase at all and then if I turn it the other way it will not decrease. I thought maybe it was just a bum encoder so I tried the other one and got the same thing. Then I thought maybe my test code was wrong so I wired up a motor encoder and it worked perfectly. I then wired the outputs of the encoder to LEDs and they turned on and off as expected. Is there something I might be missing here?

jmg

tosjduenfs wrote: »

I then wired the outputs of the encoder to LEDs and they turned on and off as expected. Is there something I might be missing here?

You've answered your own question : If you have proven the Encoder is OK, then yes, there is something you are missing.
Have you debounced the signals ?

tosjduenfs

This is the first time I have used a mechanical switch type encoder, and also the first time I've heard of debouncing. Instead of wiring up the debouncing circuit I found I tried simply pulling the encoder output pins to ground with some resistors. Now the encoder works but will step in multiples of 4. I then tried shorting the encoder pins with a 0.01uF cap and it reads in multiples of 2. Either way the encoder reads reliably now, I suppose I'll just scale the output.

Duane Degn

tosjduenfs wrote: »

I wired them per the data sheet and grounded the case.

I don't see a wiring diagram in the datasheet. How did you wire it up?

I'm using these from SparkFun myself:

https://www.sparkfun.com/products/10982

Both the encoder lines are pulled high.

Is debouncing quadrature encoders needed? I'm inclined not to think they need it. Quadrature encoders shouldn't accumulate bounce errors anyway. Proper quadrature encoder code should keep track of where the encoder is whether or not the lines bounce.

How does one debounce quadrature encoders? I have lots of projects which use quadrature encoders both as knobs and monitoring motors and I never worry about debouncing the encoders.

T Chap

I only put a very large resistor as a pull down in case the encoder is disconnected. You should not need any debouncing. There must be something not wired correctly. You would only use a cap if you are turning very slowly, best to not use any caps.

Oops sorry that device is not active, it only A, B, and common. So it looks like it does need pullups and common going to the same ground as your Prop. It should have pin C going your board GND.

jmg

tosjduenfs wrote: »

Instead of wiring up the debouncing circuit I found I tried simply pulling the encoder output pins to ground with some resistors.

Before this, you had not used any resistors ?

tosjduenfs wrote: »

Now the encoder works but will step in multiples of 4. I then tried shorting the encoder pins with a 0.01uF cap and it reads in multiples of 2. Either way the encoder reads reliably now, I suppose I'll just scale the output.

Do you mean 2 caps to ground, or a cap across the 2 pins ?

Check the fine print, from memory not all Encoders match Steps with Detents
eg I noticed they offer a 24 detent one, and yours was 12 step ?
Maybe they use the same core, just change the detent molding ?

Addit:: wire the LEDs back in, and watch them as you turn the encoder.

Duane Degn

jmg wrote: »

Check the fine print, from memory not all Encoders match Steps with Detents

Good point. Now that you mention it, the encoders I use increment four steps per detent.

This isn't a big deal. One just adjusts the software to compensate. IIRC, I can get less than four steps if I carefully turn the encoder and fight the detent.

T Chap

Just divide the count by 4 if you want 1 count per detent.

The datasheet says 12 detents per rev. A 12PPR encoder will give 48 counts per rev. So it is 4 counts per detent.

tosjduenfs

Duane Degn wrote: »

I don't see a wiring diagram in the datasheet. How did you wire it up?

I'm using these from SparkFun myself:

https://www.sparkfun.com/products/10982

Both the encoder lines are pulled high.

Is debouncing quadrature encoders needed? I'm inclined not to think they need it. Quadrature encoders shouldn't accumulate bounce errors anyway. Proper quadrature encoder code should keep track of where the encoder is whether or not the lines bounce.

How does one debounce quadrature encoders? I have lots of projects which use quadrature encoders both as knobs and monitoring motors and I never worry about debouncing the encoders.

Well the data sheet doesn't have a wiring diagram it simply shows which pins are quad output (A and and which is the common (C). I wired it with A and B going to prop I/Os and C to Vcc.

T Chap wrote: »

I only put a very large resistor as a pull down in case the encoder is disconnected. You should not need any debouncing. There must be something not wired correctly. You would only use a cap if you are turning very slowly, best to not use any caps.

Oops sorry that device is not active, it only A, B, and common. So it looks like it does need pullups and common going to the same ground as your Prop. It should have pin C going your board GND.

Ok, So It seems I may have it backwards. The common goes to ground and I pull up the Quadrature outputs. I'll try this.

jmg wrote: »

Before this, you had not used any resistors ?


Do you mean 2 caps to ground, or a cap across the 2 pins ?

Check the fine print, from memory not all Encoders match Steps with Detents
eg I noticed they offer a 24 detent one, and yours was 12 step ?
Maybe they use the same core, just change the detent molding ?

No at first I wired it like I said above with Common to Vcc. Then I tried it with 2 resistors one on each quad output pulling it to ground and that's when it would count by multiples of 4. Then with resistors still installed I shorted a cap across the two output pins and it was counting by 2s. I'll try what Chap said with pulling the output pins high and the common to ground. The data sheet says 12 detents and 12 pulses per revolution.

tosjduenfs

Ok well I tried what Chap said. Output pins pulled high and common to ground. I still get it counting in multiples of 4. If I turn it slowly enough between detents I can see each increase of 1 until hits the multiple of 4 at the detent. I think I'll try some different encoders. Perhaps I'll try the one Duane suggested however I would prefer a panel mount encoder.

jmg

As long as you know WHY it counts multiples per detent, why not just divide the result ?

ErNa

I have used similar type of encoders from ALPS and if you look to the timing of those switches you see, the transitions are not symmetrical! That is: the designers of these products didn't get the catch of a quadrature signal. In the Bourns and Chinese datasheet the signals seem to be symmetrical. But who knows. I had 2 transitions per detent, one close to the other and not stable, the other one was stable. So I divided the output by 2 to have a stable result.
One of the advantages of a quadrature signal is: hardare debouncing is not needed. A bounce represents forward backward, and if you see the spike, you will have an count, the next moment the spike is gone and you will count back. If you miss the spike, nothing happens.

T Chap

Let me rephrase what was posted above



Just divide the count by 4 if you want 1 count per detent.

The datasheet says 12 detents per rev.

A 12PPR encoder will give 48 counts per rev. So it is 4 counts per detent. Which means, the devices IS designed to give 4 counters per detent.

If you only want to have 1 count per detent, then whatever the count is just divide it by 4.

Your device is working perfectly when you get 4 counters per detent.

tosjduenfs

T Chap wrote: »

Let me rephrase what was posted above



Just divide the count by 4 if you want 1 count per detent.

The datasheet says 12 detents per rev.

A 12PPR encoder will give 48 counts per rev. So it is 4 counts per detent. Which means, the devices IS designed to give 4 counters per detent.

If you only want to have 1 count per detent, then whatever the count is just divide it by 4.

Your device is working perfectly when you get 4 counters per detent.

Hmmm.

So a 'pulse' is the entire sequence of pin1=high -> pin2=high -> pin1=low -> pin2=low (or vice versa) where each step change in either input is equal to one count. I guess I thought the whole sequence would be equal to one 'count'. Mystery solved.

tosjduenfs

Thus the 4 counts per pulse. Got it. Since the motor encoder I tried has no detents, that must be why I was confused. And now that I look at the specs of the motor encoder it specifies COUNTS per revolution, where the rotary encoder specifies PULSES per revolution. I suppose I did not understand the distinction. Thank you very much.

evanh

Ya, all good learning. They are also known as quadrature encoders, because they produce 4 distinct states per pulse cycle. Needless to say the software, or hardware, counts each state as it occurs.

For this to work the engineering of said encoders is required to have 50/50 pulse shape and 25% phase shift between the two channels. Conveniently, this is also the best config for reduced noise so it's a win-win setup.

Duane Degn

evanh wrote: »

For this to work the engineering of said encoders is required to have 50/50 pulse shape and 25% phase shift between the two channels.

If your software assumes each transition will be equally spaced then yes, you need 25% phase shift but a quadrature encoder will still work well as long as the two channels don't transition at the same time.

I'm working on encoder software which measures the speed based on the time between transitions but I keep track of both the the time between transitions and also the time for a full cycle. If the quadrature encoder wasn't precisely made (and many aren't) monitoring the time between full encoder cycles can make up for the inaccuracies in the phase shift of the channels.

evanh

An easy method is simply sum a small rolling group (aka windowed) and work at a higher resolution. Like an average, this has the bonus convenience of also taking the edge off slow pulse rates while being kept as an integer and avoiding any rounding errors.