Using an Arduino Nano to read a 20-step rotary encoder switch.
By Julian
Youtuber, shed dweller, solar charge controller aficionado
Good morning all…
Youtuber, shed dweller, solar charge controller aficionado
This site uses Akismet to reduce spam. Learn how your comment data is processed.
needs caps at the rotary switch buddy
Resistance is futile! Be susceptive to trying out this simulator! Stumble Upon androidcircuitsolver on google
I'm after a rotary switch, 10 position, with push switch built in. Any ideas??
Very nice videos . Ive been constantly waching them all but that microphone of yours is hissing way too much. The high piched tone is cutting thru my brain.Where is the base? No where to be heard I suppose. Please change the microphone or do something about it. It sounds terribly annoying. Thank you.
where can i buy 20-Position
Rotary Switch ???
Thank you, kind sir
Hi Jullian. Did you ever resolve all the problems with using manually operated mechanical REs. I'm getting close to sorting them without the use of interrupts although I've resorted to HW debounce. (RC + 74HC14).
which video is the follow up where you implement the rotary encoder with interrupts?
Thank you so far but part 3 would be the one, I really need.
It is not necessary to debounce encoder buttons as long as you use the correct software algorithm to interpret the pulses. Basically, combine the PHA and PHB signals into one state variable, and track the direction you are moving as you go through the sequence. Bounce will just cause a back-and-forth movement between adjacent states, so as long as you only register a count when you move to the rest state with the right direction setting, bounce won't cause double pulses.
I made a project once that had 3 encoders connected directly to the Arduino, and 7 pushbuttons connected to an I2C port expander. I didn't do extensive tests to make sure I never missed a pulse, but I never noticed any problems when I was testing it.
I think this is an inherent problem with encoder switches in general. My car radio uses one for volume. If I turn it slowly, the volume responds smoothly. If I spin it fast, the volume responds very little if at all. Also, you would not use a knob with a pointer on it. It's not a matter of the knob position being back where you started from. You would just turn the knob until you got the desired result.
I want to use this type of switch in some of my projects so this tutorial has been really helpful. It has given me a better understanding of how the switch works in the first place. Thanks again, Julian.
I found it impossible to get reliable operation by taking this switch directly into the Arduino even with an RC filter on the input partly because, as you said, the problem is not bounce but noise which is very difficult to deal with in software.
One solution is to add a SN74AC14N hex schmitt inverter between the encoder and arduino.
I used a 10k pull-up followed by a 100R series resistor and a 470n capacitor between input and 0V of the schmitt inverter.
This hardware removes the noise so effectively that this minimal, interrupt-driven code triggered by a rising edge on the clock input is all that is required for perfect glitch-free operation:
void rotaryEnc()
{
if (!digitalRead(datPin))
{counter++;}
else
{counter–;}
}
I also used exactly the same hardware for the push switch input and it completely removes the need for software de-bouncing.
Old video but my suggestion to you is to use interrupts on both a and b. That's the way I'm using rotary encoders and it almost never misses a pulse even in a big menu system.
The only proper way to use any quadrature encoders is to generate on both channels (A & B) an interrupt on any flange (falling or rising) and at the given interrupt check the AB channel state and compare them with the state before the interrupt occured. It gives you 16 possible states, some of them are errors (you can skip them) some of them are an increment and some of them a decrement.
Try using a couple of decoupling capacitor whilst looking for the rising edge with an interupt if using the whole flashing led thing (i presume thats your way of showing standard use)
to my opinion: u should decode the switch Gray code position after debouncing
I really enjoyed parts 1 and 2 of the rotary encoder series, where is part 3?