please help me find a rotary encoder

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.

http://au.mouser.com/

Would you please be able to recommend to me such an encoder and perhaps give me a link to it?

it doesnt have a puch button.

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.

You can put larger knobs on them, like this one

Here's one, from digikey, that I have used
http://www.digikey.com/product-detail/en/bourns-inc/PEC12R-4220F-N0024/PEC12R-4220F-N0024-ND/4499652
Be sure to use the filter circuit on page 2 of the datasheet
Here's the right angle mount version on a PCB (for downloading code from SD card into other Arduino boards), note the 6 filter components right above it.
http://www.digikey.com/product-detail/en/bourns-inc/PEC12R-2125F-N0012/PEC12R-2125F-N0012-ND/4499641

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.

Yeah I guess jog wheels need more res and don't want the detents.

CR, 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.

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.

(Rotary Encoder: H/W, S/W or No Debounce? | H i F i D U I N O)

So the easiest solution is to add an RC low-pass filter to filter out these fast transitions:

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 :slight_smile:

Getting back to the OPs question then, maybe something like this

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

why is it easier to do it in software?

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.