Switch encoder problems

There is a considerable body of lore about using these devices. If you search c.a.e for talk of quadrature encoders, you'll find threads going into great detail on this topic.

When using a similar sort of device (Panasonic EVQ-WK encoder wheel with click function) on a consumer product, I had great success with the following algorithm:

Periodic interrupt: if (input A changed state) { if(input A) add_ring_buffer ("A"); // rising edge else add_ring_buffer("a"); // falling edge } if (input B changed state) { if(input B) add_ring_buffer("B"); // rising edge else add_ring_buffer("b"); // falling edge }

If the last three characters in the ring buffer are "ABa" or "abA" then you scrolled one click in the + direction.

If the last three characters in the ring buffer are "Aba" or "aBA" then you scrolled one click in the - direction.

(This is from memory so hopefully there are no errors... and my interrupt rate was rather slow, 60Hz IIRC).

The best luck I've had with encoder wheels like this is a state follower. The output of the wheel is a 2-bit gray code, and you want to keep track of it. The state follower method maintains a counter who's last two bits are forced to correspond to the position of the wheel. Whenever those two bits roll over from 0 to 3 the upper bits of the counter are decremented, and whenever those two bits roll from 3 to 0 the upper bits are incremented.

The only tricky thing is that you want your counter to be straight binary, so you have to convert the wheel's position from gray to binary.

The algorithm goes like this:

old state wheel position action new state (binary) (gray)(binary) (binary) [n] 0 0 0 0 (0 0) 0 [n] 0 0 [n] 0 0 0 1 (0 1) + [n] 0 1 [n] 0 0 1 1 (1 0) ? [x] x x // illegal transition [n] 0 0 1 0 (1 1) - [n-1] 1 1 // rollover down [n] 0 1 0 0 (0 0) - [n] 0 0 [n] 0 1 0 1 (0 1) 0 [n] 0 1 [n] 0 1 1 1 (1 0) + [n] 1 0 [n] 0 1 1 0 (1 1) ? [x] x x // illegal transition [n] 1 0 0 0 (0 0) ? [x] x x // illegal transition [n] 1 0 0 1 (0 1) - [n] 0 1 [n] 1 0 1 1 (1 0) 0 [n] 1 0 [n] 1 0 1 0 (1 1) + [n] 1 1 [n] 1 1 0 0 (0 0) + [n+1] 0 0 // rollover up [n] 1 1 0 1 (0 1) ? [x] x x // illegal transition [n] 1 1 1 1 (1 0) - [n] 1 0 [n] 1 1 1 0 (1 1) 0 [n] 1 1

Each time you sample the wheel you convert the wheel position to straight binary, compare that with the last two bits of the counter, and adjust the counter if necessary. The 'action' column in the table above shows what to do with your counter. Note that there are four illegal transitions -- the encoder should never transition both bits at once. If it does then either you're sampling too slow, turning the knob too fast and getting bounce, or you have a hardware problem. Figuring out what to do in this case is your problem.

The nice thing about this algorithm is that the code is simple and as long as one channel has settled before the other one transitions it is bounce proof -- if you do have a bouncing switch the counter state may dither back and forth before it settles, but it won't stop the wrong value. You may end up loading the synthesizer a few extra times, but you won't have the wrong value in there when you are done.

Quadrature encoders are a field in themselves :)

You may find that the 5ms 1t 15rpm is equivalent to your 40ms at 2rpm - ie the bounce will get worse at slow speeds.

The trick is to either blank out the bounces, or to not loose edges - in this latter case, the decode logic simply 'follows the bounce', as it will just do +1/-1 +1/-1 until it settles.

Good Quadrature code will tolerate 'edge oscillation' where one signal jitters HLHL.

If the user gets a display of the nett result, you can be a little more lax about max spin speeds etc, but if this were a rotary position encoder, that would be important.

-jg

Unfortuneately I can't use interupts this time. The board is already done and the inperupt pin is in use, but it will be worth a try the next time I need to use one of these encoders.

Thanks Mike

Read again carefully. I said it was a periodic interrupt, NOT an interrupt on either of the input pins. It is a _periodically polled_ algorithm. You set a timer to fire every 1/60th of a second and look at the two input lines in the ISR.

The micro I was using did not have any GPIOs. (It did have interrupt pins but there was no way of reading their state directly in software).

I'm not sure, but it looks like this algorithm might be immune to the problem of the encoder stopping between detents. Is this correct?

Thanks Mike

DUH! I never thought of that.

Yeah, I don't care as long as it goes up or down 1 station per detent.

Thanks Mike

Without knowing what the encoder _does_ when it stops between detents I can't say. Where you will have problems is if the encoder sits there vacillating between two values -- should that happen, and should you be using the simple and obvious rule for loading your synthesizer, your tuning will be jumping up and down continuously.

Ok, gotcha.

and that all probably depends on exactly where it stops.

Yup. I'd check to see if it's just the one encoder in the batch that does it, or if the other's do to.

OTOH, you can probably learn pretty quickly to make sure the thing drops into a detent before you let go -- after a while it'll become automatic, and you'll be surprised when your significant other can't operate your radio.

Is that a mechanical problem or an electrical one ? How exactly does it stop between detents ?

-jg

The ones we use have one output guaranteed at the detent (A guaranteed 'off'), but the other (B) can be in either state (or can go back and forth). Ignoring that, there are (ideally) four edges per detent.

Best regards, Spehro Pefhany

That's interesting. The one that I used has one transition per detent

-- i.e. each 'click' is 00, 01, 11, etc.

I've tried 3 of them and they are all the same.

That's the problem. The only reason I built this receiver is for my wife to take to the office. She has tried 3 different commercial radios and none of them work there because of all the interference.

Mike

Definately a mechanical characteristic of the encoder.

When I rotate the shaft and let go of the knob, the position of the shaft is not in a detented position, so the switches do not return to their rest position.

Mike, I'm an embedded programmer and, although I cannot be sure about this case because I can't say I have a complete feel for the problem you've discussed, I suspect that I can add some code for you to make it work satisfactorily. I've done debouncing on PICs before and I've done quadrature decoding in software before, as well. All successful. (I also have a sack full of very good quality optical encoder dials at some 32 pulses per rev, if push comes to shove.)

I'm interested in having such a receiver and I'd be happy to consider suggestions. I'd need to know what tools you are using, though, and I can't promise a hard schedule. My email is in the clear.

Jon

This particular encoder at rest on the detent has both switches open. When the shaft is rotated to the next detent both switches will close then open again. That would be a leading and trailing edge for each switch, so I suppose that would be four edges per detent.

I hooked up a digital scope to the 2 switches and there isn't all that much bouncing of the edges. It's hard for me to explain, but what is happening is that when the shaft stops the detent doesn't hold it good and tight and it's very easy to get a partial rotation out of the detent position then rocks back to rest. resulting in another switch transfer. That is when it doesn't go far enough to just stay between detents with the switches closed. I need to treat them as if they have no detent and can be in any position at rest.

Ok Jon, I'll contact you.

Mike