Using a KY040 Rotary Encoder with Arduino

I was playing with RGB LEDs for my Anamatronic Evil Eyes Project. I had some rotary encoders sitting out that I had just received in the mail from ebay. I figured this would be a great chance to learn to use the rotary encoder – turn it to change the RGB’s color and maybe brightness.

I figured this would be slam dunk. Well no, it wasn’t I ended up having quite a few problems.

The KY040 looks like this:

First, the KY040 doesn’t seem to be very well documented, particularly in regards to connecting it to an Arduino.

My main reference ended up being this forum post in arduino.cc. Even that didn’t give much of an explanation of the pins on the board.

Here is my take: a normal rotary encoder has 3 connections: A, B, and C. The KY040 has CLK, DT, SW, +, and GND. It is essentially a simple rotary encoder plus a push button switch and integrated pull-up resistors. The CLK is equivalent to A, DTA to B, and GND is C. SW is the push button switch and you provide a VCC signal so the integrated pull-up resistors will work.

Using the instructions in the aforementioned website, I wired the encoder to my arduino Nano like this:

This hardware setup, plus the program in the example ‘kind’ of worked for me. The problem was, it was inconsistent. I’d rotate the knob one way slowly and most of the time in would increment by one, but sometimes by two and sometimes it would actually decrement.

The behavior was too inconsistent for what I would expect. It sounded like maybe a debounce problem, but I had put on the caps to prevent such problems.

So I pulled out my largely (so far) unused logic analyzer and connected it to CLK (channel 0) and DT (channel 1). I set the logic analyzer to start recording when pin 0 went low.

I turned the encoder on click right:

and one click left:

It looked good. On the right rotation, when CLK goes low, DT is currently low. On left rotation when CLK goes low, DT is high. Seems to work!!??

Then I decided to zoom way, way in on channel 0:

Uh oh. That’s not a clean signal. I took a look at channel 1 as carefully:

Even dirtier. But I supposedly had capacitors to keep this from happening. Well, I did BUT rather than connect the directly to pins 2 and 4 of the nano, I had them at the other end of the bread board just because it had been easier to put them there. I connected the caps directly between pins 2 and 4 and the ground. The noise is now gone.

With the noise problems solved, I began playing with the original code to see if I could make it ‘tighter’. I’ve used interrupts some, but I’m far from an expert and I found this website to be quite informative.

The following code works quite well for me and is in step with what I’m going to want for my RGB LED test circuit.

#include <Arduino.h>

// -----------------------------------------------------------------------------
// constants

const int                                 PinCLK   = 2;     // Used for generating interrupts using CLK signal
const int                                 PinDT    = 4;     // Used for reading DT signal
const int                                 PinSW    = 8;     // Used for the push button switch

// -----------------------------------------------------------------------------
// global vars

volatile int                             virtualPosition    = 0;

// -----------------------------------------------------------------------------
// forward decls

void isr();
void loop();
void setup();

// -----------------------------------------------------------------------------
// Interrupt service routine is executed when a HIGH to LOW transition is detected on CLK

void isr ()  {
    if (!digitalRead(PinDT))
        virtualPosition = virtualPosition + 1;
    else
        virtualPosition = virtualPosition - 1;
    } // isr

// -----------------------------------------------------------------------------

void setup() {
    Serial.begin(9600);

    pinMode(PinCLK,INPUT);
    pinMode(PinDT, INPUT);
    pinMode(PinSW, INPUT);

    attachInterrupt(0, isr, FALLING);   // interrupt 0 is always connected to pin 2 on Arduino UNO

    Serial.println("Start");

    } // setup

// -----------------------------------------------------------------------------

void loop() {

    int                                    lastCount = 0;

    while (true) {
        if (!(digitalRead(PinSW))) {        // check if pushbutton is pressed
            virtualPosition = 0;            // if YES, then reset counter to ZERO
            while (!digitalRead(PinSW)) {}  // wait til switch is released
            delay(10);                      // debounce
            Serial.println("Reset");        // Using the word RESET instead of COUNT here to find out a buggy encoder
            }
        if (virtualPosition != lastCount) {
            lastCount = virtualPosition;
            Serial.print("Count = ");
            Serial.println(virtualPosition);
            }
        } // while
    } //loop

After writing this post up, I played with the encoder further and if I spin it fast enough, I still have debouncing issues. This is getting beyond my understanding but it appears that if the legit transitions happen fast enough, the capacitor can’t smooth out the bogus spikes.

I did a little research on this and found the recommendation to use millis() in the ISR to determine the length of time between interrupts. If a successive interrupt happens too quickly it gets ignored.

My new isr procedure looks like this:

void isr ()  {

    static unsigned long                lastInterruptTime = 0;

    unsigned long                       interruptTime = millis();

    // If interrupts come faster than 5ms, assume it's a bounce and ignore
    if (interruptTime - lastInterruptTime > 5) {
        if (!digitalRead(PinDT))
            virtualPosition = (virtualPosition + 1);
        else
            virtualPosition = virtualPosition - 1;
        }
    lastInterruptTime = interruptTime;
    } // ISR

Using 5ms works pretty well. I can spin the rotary encoder pretty fast and it registers every single position. But if I spin it fast enough, it will start dropping positions; however that is preferred to what I was seeing – it would actually think the rotary encoder was being turned opposite to its actual direction.