Rotory Encoder Woes

jpanhalt said:

In one of the later iterations of the VFO project using a DDS module ( See:VK5TM's stuff on the DDS modules), they used the speed of encoder rotation to determine the size of the encoder steps, much like some modern mice do. That adds a new dimension (time). A fast turn may increment by 10's of kHz, while a slow turn may only increment 10 Hz per revolution or so. Your proposed method does much the same thing, but I think users may be more accustomed to the mouse way.

John

Click to expand...

Hi John,

Well using the digit select method makes it a precise way to change the frequency digit by digit. The "acceleration" way is a bit strange sometimes, and i dont think it would be too cool for this particular project because there are so many digits. Using a second encoder however would allow switching to digits quickly.

The method of changing the quantity slowly, then faster, is referred to as "acceleration", because it is able to speed up the speed of change. Another typical use is in a Windows programming environment when we included an "Up/Down" type control, which is a little arrow that points up and a little arrow that points down, and when we click on the little arrow the counter goes up, and if we hold the mouse button down the counter goes up faster after a given time period, like 1/2 second. They also allow another setting which we might call the "Jerk" (after the physical unit) which speeds up the speed of the speeding up due to the first time period. To specify this we would call a routine with parameters such as:
{0.5, 2, 5}
which would mean the count would start to change faster after 0.5 seconds, then after 2 seconds the count would change even faster yet, then after 5 seconds still yet faster. It would also have a set of rate specs associated with it like:
{1,5,10,50}

where 1 is the default, 5 is after the 0.5 seconds, 10 is after the 2 seconds, and 50 is after the mouse has been held down for 5 or more seconds.

For setting the frequency i am not sure how well this would work, but hey you could try it and make a short video. The thing i dont like is that what if we turn it for 5 seconds and the second digit starts to change like 0, 1 ,2 and we get to 3 but then go over to 4, how do we get back to 3. We'd have to stop, then turn the other way and wait another 5 seconds. But try it and see what you can come up with, and try to make a video if you can. I'll try to make a video of mine later so you can see how nice it works.
But having a second encoder would be cool too, to allow changing the digit select that way. That way we can 'point' to any digit we want to change in maybe a second.

I guess we can also think about other things too, like sweep. We'd need a sweep start frequency and end frequency, and rate of change, and log or linear sweeping. More settings we'd have to incorporate. Typical audio sweep is from 10Hz to 20kHz, for FM modulation we might want it to sweep up and down repeatedly, or just change between two or more frequencies. Should be fun to try

MrAl Can you link the actual encoder specs for the new one? I am surprise it doesn't use Gray Code as in the old one.
In any case, I would make a transition diagram for xx for both encoders and allow next state for both encoder/decoders to come up with a common solution.
**broken link removed**

One way to make the new one look like the old one is add unequal propagation (RC+diode) so the when the switch closes to "1" it stays there longer from 01 to 10 so it becomes 01 11 10 due to a cap or a cap with diode and resistor if source is not open collector.

SO choose a Cap such that the pull up R*C time constant is sized appropriately to your detection rate and rotation rate.

Hi Tony,

I may have made an error when i reported the sequence 01 10 because there is always an in between state 11, but one encoder stops there and the other encoder does not stop until it gets back to 00.

In any case, i tested both encoders again and carefully logged the LED's that come on and stay off during the course of each click. As the attachment will show, they both go through the intermediate state but one stops there and the other doesnt.

I also converted the test setup LED observations to the actual code the uC chip would see this time. So a '1' indicates that the uC chip would actually read a '1', and likewise for a '0'. So if the code shows 10 for example, the microcontroller chip would see a '1' on the first pin and a '0' on the second pin.
I also show the relationship between the CLK and DAT lines and the A and B data sheet lines, but it's hard to tell if this is accurate because it is hard to follow the traces on the boards themselves. They do look the same however.
The waveshape on the PEC11L or PEC16 series encoders seems to match the BLUE body encoder, which is the top one in the diagram.

So the codes came out to:
BLUE ENCODER: 11 10 00 01 11 for one click, and 11 10 00 01 11 for the next click (same).
GREEN ENCODER: 11 01 00 for one click, then 00 10 11 for the next click.

So the blue encoder always stops at both internal switches open, while the green encoder sometimes stops with both open and sometimes with both closed. Both encoders of course always start from the last code that they put out because that is where they 'rest' after the shaft is no longer turned.

MrAl said:

So the codes came out to:
BLUE ENCODER: 11 10 00 01 11 for one click, and 11 10 00 01 11 for the next click (same).
GREEN ENCODER: 11 01 00 for one click, then 00 10 11 for the next click.

Click to expand...

That's really of minor importance, and can be handled with little effort. More importantly, it is good to see that it is a proper Gray code, because the set of transitions: 00 01 10 00 would have led to some ambiguous counting. The transition from 01 to 10 could never happen with both outputs changing at precisely the same time—one would always switch before the other. A make-before-break transition would lead to: 00 01 11 10 00 which would be a proper gray code, and unambiguous. However, a break-before-make type of transition would lead to: 00 01 00 10 00 which could not be decoded correctly without some inference about debounce time.

BTW, I meant to add that you can get very inexpensive encoders from DigiKey and Mouser, with the added benefit of a proper datasheet so that you'll know what you're getting before you order it. I've used the inexpensive Panasonic encoders for my projects, though, I haven't used the ones with the built-in pushbutton. However, TT Electronics makes a similar style, which includes the pushbutton, and they are only about $1.40 each.
https://www.digikey.com/product-detail/en/EN12-HS22AF20/987-1195-ND/2408773
At these prices it's hardly worth dealing with mystery encoders of unknown specs.

Hi,

Yes, i was thinking that too, but then again they are not hard to test, at least not the mechanical switch type. Once you test them you have the code it puts out, and it only takes two LED's and a resistor or two to test them.

True enough. In my situation though, I've written a bunch of encoder routines in assembly language, and I'd rather not have to redo them because of a non-standard encoder code, especially when inexpensive quadrature (Gray code) encoders are readily available. (You may have missed my post #45, because I posted it almost simultaneously with your last post.)

Hi Bob,

Oh yes, you are right, buying from a company that shows the data sheet is much better. Unfortunately i already have 5 of these to use up
But they seem to work ok once the code is found. And i think they are one of the PEC16 series by Bourns, and their data sheet lists the output waveform.

Unfortunately though, if you look at that data sheet you still wont be able to be sure how the code is output. That's because it looks like they show a generic waveform and they dont make it perfectly clear what each click does. I will post the drawing they give so you can take a quick look. Look at the waveform near the bottom of the page and see what you can make of it...

Hey Al,
I agree with Bob, they both have to be Gray Codes.

The Blue is a full Gray cycle per detent x 40 per rotation of 360 deg or 9 degrees per gray code cycle.
The Green is a half Gray cycle per detent x30 per rotation of 360 deg. or 24 degrees per Gray Code cycle.

Mechanical rotary dials are no way as nice a user feel as ball-bearing optical jog controls or finger dial-jog controls.

Although I have seen an MP3 player with capacitance tough PCB for a DJ controller in a radial PCB pattern with very nice user feel. The only moving part is the user's finger.

HP has always used high quality optical rotary controls with very smooth bearings with a light weight viscous feeling to control 10 digits with one finger with high acceleration, velocity and fine position control with step size switches.

Hi Tony,

Yes about the Gray code, first, you are one of the few people that get the spelling right, so congrats to you

Second, yes, I had reported the code incorrectly one time. Instead of:
00 10 01 00
it was:
00 10 11 01 00

or if you care to invert:
11 01 00 10 11

or turned in the other direction:
00 01 11 10 00

And yes, one of the encoders only goes half way or something so it does not register any click until after two clicks with the code that works with the encoder that spits out the entire sequence as shown above.

I am happy though that i found out now that there are at least two types out there. I have also read about people complaining about downloaded Arduino code that did not work for them and the symptoms sound just like they had the other encoder's code for their encoder.

Yes those expensive encoders do look nice. Not sure if i want to spend that much though just for the encoder, as that would then cost more than the whole frequency generator including u controller board plus frequency generator chip

Also, when i plug the half code encoder in where the full code encoder went, it takes two clicks to get it to register one single count. It might be tricky to get both to work with the same code, but if you care to think up some code that you think will work with both types i'll try it out with both encoders as the program code is so easy to change.

For the cheapest solution I would extract the 3 button optical mice GUTS and seal the detent-type clicking wheel from dust. for front panel access.

This gives you high resolution quadrature encoding, with great user touch feel, plus left / right shift digits and and enter button. ( 5 button mice give even more options. )

It is only possible to distinguish between a half cycle and full cycle gray code encoder by a smart logic that detects the idle state for presence of the half-cycle encoder after a few random spins . with some clever scheme.

the extra buttons could be used for manual sweep instead of set BCD digits like going from 999.99 to 1000.xx, which otherwise would be a pain.

MrAl said:

Yes those expensive encoders do look nice. Not sure if i want to spend that much though just for the encoder, as that would then cost more than the whole frequency generator including u controller board plus frequency generator chip

Click to expand...

Then again, how much do you value your time? With the higher quality encoder, you may have saved yourself a lot of hours.
Just kidding bud.
I was considering getting one of those encoders for a little project I plan to do, but after seeing the trouble you are having I think I might just get one of those 6 pin ADC's and use a analog pot. It will actually be a lot cheaper too.

Forgive me for barging in here, but have you solved your problem?
I have many rotary encoders, some expensive (optical, no detents) and some cheapo Chinese ones (10 for $3 detents with push-switch) so I could test them out and provide results. Also, I have never actually written my own routines for them, so if you're still having issues with yours, it would be an excuse for me to knock up some code (interrupt based, and polling based) in C to test it out.

For frequency counters where you only have one encoder, used a lot, with a huge range, I would definitely advise a more expensive encoder. Or, a DIY optical one. I made something similar using the head off an old VCR, and a very simple encoding wheel, along with IR LED's/detectors. Worked like a charm.

Tony Stewart said:

For the cheapest solution I would extract the 3 button optical mice GUTS and seal the detent-type clicking wheel from dust. for front panel access.

This gives you high resolution quadrature encoding, with great user touch feel, plus left / right shift digits and and enter button. ( 5 button mice give even more options. )

It is only possible to distinguish between a half cycle and full cycle gray code encoder by a smart logic that detects the idle state for presence of the half-cycle encoder after a few random spins . with some clever scheme.

the extra buttons could be used for manual sweep instead of set BCD digits like going from 999.99 to 1000.xx, which otherwise would be a pain.

Click to expand...

Hi Tony,

Yes that sounds very good. I havent given any thought to the dual encoder code yet so im not sure which way i will go with that. I think one bounces more than the other too so that may be a problem also.
I see what you mean about going from 9999 to 10000 or similar, as it requires resetting 5 digits just for that one little increment. Something to think about.

Mikebits said:

Then again, how much do you value your time? With the higher quality encoder, you may have saved yourself a lot of hours.
Just kidding bud.
I was considering getting one of those encoders for a little project I plan to do, but after seeing the trouble you are having I think I might just get one of those 6 pin ADC's and use a analog pot. It will actually be a lot cheaper too.

Click to expand...

Hi Mike,

Well you are right in that it could save a lot of time with the better encoder because the cheaper one might die out after several uses. They are rated for 100000 cycles, but you never know, as they are after all mechanical switches.

Dont worry about the 'trouble' though, because once you have the code right it works great. Every click is caught, clockwise or counter clockwise. The pots do wear out faster i think. They are rated by the manufacturer though so you could check that too. They also do not allow turning all the way around unless you can find one that allows that. That means limited range.
For example, you could not set 9 digits with a pot unless you did not mind turning it left and right for every digit, just like the encoder. Set digit 1, then press a button to get to digit 2, set that, then digit 3, etc.
Many uC chips already have the ADC too so that would make it simple for a pot though.

Blueteeth said:

Forgive me for barging in here, but have you solved your problem?
I have many rotary encoders, some expensive (optical, no detents) and some cheapo Chinese ones (10 for $3 detents with push-switch) so I could test them out and provide results. Also, I have never actually written my own routines for them, so if you're still having issues with yours, it would be an excuse for me to knock up some code (interrupt based, and polling based) in C to test it out.

For frequency counters where you only have one encoder, used a lot, with a huge range, I would definitely advise a more expensive encoder. Or, a DIY optical one. I made something similar using the head off an old VCR, and a very simple encoding wheel, along with IR LED's/detectors. Worked like a charm.

Click to expand...

[I replied to the other posts first, this reply is last]

Hi there,

Yes building one from scratch would be interesting too. A 'ring' of LEDs like that linked in this thread somewhere would make that much simpler too. Only 16 LED's but that would be enough for a digit dial that only has to go from 0 to 9.
Something else to think about.

If you would like to test some code on the encoders, then maybe you can try to come up with a set of code that will work with both encoders without having a 'test/calibrate' phase (ie where you have to turn the encoder to let the software know what kind it is). If it can detect both encoders properly that would be nice. As Tony points out however, that may be difficult or impossible without that calibrate phase of operation.

The encoder problem is solved insomuch as the different code is used for the different encoders, but if we can come up with something that works with both encoders without changing any software, so much the better

N wide Gray codes or just 2 bit quadrature are designed to be capable of being debounced with logic without missing cycles.
optical encoders are certainly great, only marred by cheap plastic wheels and dust.

Hello Tony,

Yeah i had a couple mice that picked up a thread from clothing and it wound around the wheel shaft. What a pain, as it had to be taken apart to get the threads out.
The wheel winds up the thread and you dont realize it until it gets very hard to turn the wheel. It's kind of funny when you think about it, but a pain to clear up because the thread(s) doesnt just pull right back out.