I have been searching through the extensive Mouser electronics online catalogue for a rotary encoder suitable to be a jog wheel for my audio daw. They have so many parts that i am a little lost.
Well you haven't said what type of rotary encoder you need or provided a link (and I ain't searching through the entire Mouser site), but I just got some of these and they are pretty good.
Professional gear often makes use of optical encoders. The resolution of the 'normal' mechanical encoders suggested by CrossRoads and Graynomad (24 pulses per revolution) is way too low when you are using large or medium sized jogwheels.
Graynomad:
why is that filtering required? It's just a digital input. I'm using the above encoder right now with just two wires connected to the CPU.
A mechanical rotary encoder consist of switches that are opened and closed in a predetermined sequence. During the switch transitions noise is generated, typically lasting from 1 to 5 milliseconds; the switch is “bouncing”. The following photo shows a rotary encoder switching and captures the first millisecond after the swtich event. Notice that for approximate .7 milliseconds the switch is “bouncing”
In order to reliable determine the state or level of the switch, it has to be “de-bounced” either by adding hardware components to attenuate the noise or by waiting in the code sufficient time after the transition has occurred.
I'm probably more a hardware than a software jock and I'm quick to add components, but the easiest solution is to debounce the inputs in software, in maybe 30 years of writing embedded code I've never harmed a single resistor or capacitor when using a switch as an input.
For a beginner writing code though I can see that it would be much less confusing to just read a pin and have the hardware deal with the bouncing.
Interestingly the PEC11 encoder that I'm using (seems almost the same as the PEC12 linked to by CR) does not show any filtering in the datasheet even though it's rated bounce is 2.5x longer. (5mS vs 2mS).
It seems that even Bournes can't decide which is best
Graynomad:
but the easiest solution is to debounce the inputs in software, in maybe 30 years of writing embedded code I've never harmed a single resistor or capacitor when using a switch as an input.
Just out of interest: why is it easier to do it in software? Doesn't that mean that you have to deal with timing in your ISRs?
I'm not exactly sure what you are looking for but I had to replace an encoder on a CNC mill once. It was used to read the RPMs of the spindle. Best I recall it was about $100
I suppose it depends, in my case I have code already written for that sort of thing so all I have to do is something like this
if (buttonChangedState(encoder->pinA) && buttonIsActive(encoder->pinA))
if (pinRead(encoder->pinB->logical_pin) == LOW)
fsmRaiseEvent(fsm, EVENT_CW, 0);
else
fsmRaiseEvent(fsm, EVENT_CCW, 0);
I agree that there is timing happening in the background but once that code is written you never have to do it again, whereas hardware has to be done every time.