decoding quadrature encoders

[cbrun17]

Hi Henrik,

I changed the display routine as you described and it does work much better. I sure do over think some of this stuff... I did have to increase the pause to 250ms to allow for the display to update since it seemed to trip over itself a little more frequently this way.

I believe moving to either serial LCD or 7 seg LED might be the better solution.

Thanks again for your expert advise.

Chris

[Dave]

Excuse me Henrik, If you read the spec. sheet you can set the interrupt edge for the INT0 and INT1. It is not required to set it each time. Also the interrupt routine look like:
'************************************************* ********************
INC_C: 'INTERRUPT SERVICE ROUTINE FOR EXTERNAL INTERRUPT-0
'************************************************* ********************
POSITION = POSITION + 1
@ INT_RETURN

'************************************************* ********************
DEC_C: 'INTERRUPT SERVICE ROUTINE FOR EXTERNAL INTERRUPT-1
'************************************************* ********************
POSITION = POSITION - 1
@ INT_RETURN

That's all there is to it.

[richard]

When I added the mcu context save routine the display crashed. It will ~ work if I move the shaft slowly, however, moving quickly caused the code to trip over itself and lockup the screen.
My first guess was that when jumping out of the ISR, the next return in the main program uses the most recent return address on the stack and returns to the point the interrupt occurred, crashing the program.

I have not tried your code but can assure you that it is essential to save the mcu context upon isr entry and to restore it on exit . restoring the context without saving it can only lead to tears, not saving it can only lead to tears.

so good luck with that


dave
the chip used here in this somewhat hijacked thread is a 16F876 it has only one "INT" pin your suggestion just cannot work in that case.
afaik no pic16 chips can respond to rising and falling levels on an INT int pin simultaneously
its one or the other. as henrik says to do a full quadrature decode every edge needs to cause an interrupt.
RBC int can do it a single INT int cannot , the intx edge would need to be toggled on every interrupt .

secondly that circuit with all its extra bits cannot use the full resolution of a encoder its a 1x decode.

thirdly since the portb rbc pins on a 16F876 are schmidt trigger type inputs and if the chip is close enough to
the re (opto type not mechanical)no other components are required at all to do a full 4x decode , why complicate it ?

[HenrikOlsson]

Excuse me Henrik, If you read the spec. sheet you can set the interrupt edge for the INT0 and INT1. It is not required to set it each time. Also the interrupt routine look like:

Dave, I think you're misunderstanding what I'm saying.
The circuit you linked to is x1 decoder, effectively provoding 1/4 of the encoders available resolution. Your simply counting the individual lines of the A and B channels respectively. If that's enough, perfect go right ahead but if you need the full resolution of the encoder (as is the case here) then it's not going to cut it.

To use the full resolution of the encoder each and every edge of the two signals needs cause the counter the change up or down. If the encoder is connected directly to INT0 and INT1 it means that the edge causing the interrupt needs to changed on every interrupt so that it "catches" the falling edge after a rising edge etc. It's certainly doable if the PIC allows you to do it (not all do) but it does complicate things.

By using interrupt on change this is handled automatically because ANY change on ANY pin causes an interrupt so you will "catch" every edge (rising AND falling) automatically and you just need to decode the gray code in the ISR. From any given state (there's only four) you can only get to two other (valid) states, one is forward the other is backwards.

Look at this NI page on qudrature encoders, about half way down is a comparison of x1, x2 & x4 decoding.

/Henrik.

[Dave]

Henrik and Richard, I understand what it is you are trying to accomplish. The problem becomes noise and the ability of the micro to intercept the interrupts. When you are trying to capture each and every edge in a mechanically noisy environment you will undoubtedly miss an edge or two. The key to properly designing an encoder into a mechanical design is the encoder resolution. Trying to get 4x the resolution from an encoder is indeed one way to fail if the encoder is of a higher resolution than is required. I have been designing encoders into mechanical fixtures for almost 40 years. I would rather have the processor executing code rather than constantly servicing interrupts in a mechanically noisy environment. It's just my way of thinking. Good luck...

[HenrikOlsson]

If you need a certain resolution and a certain speed then it's going to result in a certain number of "counts" per second (ie a certain number of interrupts per second) no matter if you're doing x1 or x4 decoding, won't it?

The difference is that with the former you need an encoder with 4 times the number of cycles compared to the latter. As far as the number of interrupts that micro needs to service there's no difference.

In this particular case we don't know what the speed is but we know that Chris needs (or wants) a resolution of the 0.25 degrees, which his 360CPR encoder will provide with x4 decoding. He could exchange his encoder for one with 1440CPR and do x1 decoding but given that the speed at which the enocder is being moved is the same there will be an equal number of "counts" per second. Doing the x4 decode in software is however a bit more complicated than x1, I'll give you that :-)

As far as noise goes I don't see the difference in running a 360CPR encoder doing x4 decoding and running a 1440CPR encoder doing x1 decoding.

And if using an external decoder circuit, like the one you linked to, there's no need for any interrupts at all, just have two counters count the up/down pulses and differentiate periodically.

/Henrik.

[picster]

Thank you Richard. I will test this and let you know the results.

Also, though the encoder is optical, I am going through a 74C14 hex Schmitt trigger with rc filtering to remove any stray noise. all cabling from the encoder is shielded. Monitoring the output results in clean square wave with fast rise and fall times.

Chris

Out of curiosity, what R/C values did you find to be optimal on your schmitt triggers?

Picster

[picster]

Out of curiosity, what R/C values did you find to be optimal on your schmitt triggers?

Picster

Ok, I did some trials myself and ended up with R1=100k, R2=33k, C=0.1uF working well with Schmitt trigger inputs on the PIC I'm using (see circuit attached). That's with a detented encoder, using the same values for the two rotary outputs AND the built-in pushbutton.

[Ioannis]

I would use 10th of this values.

Ioannis

[picster]

I would use 10th of this values.

Ioannis

You certainly could. Yet this works great in my application, for which I am using switch polling, not interrupts. I would imagine it also depends on the characteristics of the encoder.

[Ioannis]

Of course it does. But I am worried about the input impedance of the PIC and leakage currents.

Ioannis

[picster]

Hey Ioannis,

I'm hoping you can shed some additional light on this for me.

I know the "design standard" is to use a 10k pullup for PIC inputs that switch to ground - which from my understanding is really not so much about leakage, but more about noise on the "antenna" that an input wire or trace can become. The internal weak pullups tend to work on a breadboard or on a PC board, as long as the system isn't subject to much electrical noise, but "guaranteeing" that environment is far from possible in real world applications. The internal "weak pullups" have equivalent impedance ranges from 200k to 16k, per PIC specs. Meanwhile, input impedance for ports works out to around 50Mohms per specs. I agree, it is always good to have a "solid" and unquestionable pull-up instead of something where spurious glitches can put you into nebulous range, particularly with an input that's NOT configured as a schmitt trigger and you can get all kinds of undefined questionable results. Absolutely makes sense to use "tried and true" 10k in these situations.

However, despite the above, part of the benefit of using a capacitor on the input (again, only with the schmitt trigger config) is that it will help to eliminate spurious noise, effectively shunting spikes to ground and only letting relatively persistent voltage levels through. Hence the reason, I believe, why these values may be demonstrated to work for a schmitt trigger input configuration. I picked these values around the 0.1uF capacitor since I have a ton of them.

Does this make sense, or am I missing something else that I should be considering?

[picster]

Hey Ioannis,

I'm hoping you can shed some additional light on this for me.

I know the "design standard" is to use a 10k pullup for PIC inputs that switch to ground - which from my understanding is really not so much about leakage, but more about noise on the "antenna" that an input wire or trace can become. The internal weak pullups tend to work on a breadboard or on a PC board, as long as the system isn't subject to much electrical noise, but "guaranteeing" that environment is far from possible in real world applications. The internal "weak pullups" have equivalent impedance ranges from 200k to 16k, per PIC specs. Meanwhile, input impedance for ports works out to around 50Mohms per specs. I agree, it is always good to have a "solid" and unquestionable pull-up instead of something where spurious glitches can put you into nebulous range, particularly with an input that's NOT configured as a schmitt trigger and you can get all kinds of undefined questionable results. Absolutely makes sense to use "tried and true" 10k in these situations.

However, despite the above, part of the benefit of using a capacitor on the input (again, only with the schmitt trigger config) is that it will help to eliminate spurious noise, effectively shunting spikes to ground and only letting relatively persistent voltage levels through. Hence the reason, I believe, why these values may be demonstrated to work for a schmitt trigger input configuration. I picked these values around the 0.1uF capacitor since I have a ton of them.

Does this make sense, or am I missing something else that I should be considering?

Note: 10k/3.3k/0.1uF also works with the switch I'm using, so I've changed to this configuration just to stay "standard", and I need not bother with larger caps.

[Ioannis]

I just realized that my reply post to your #92 never showed up... A mystery!

Anyway, there are no standard values and all depend on the circuit itself. If it works reliable under all worst conditions then this is your standard.

On the other hand I am worried having large pull-ups (or downs accordingly) near large electric fields of any kind.

Ioannis