When the count goes wrong

Six symptoms

Pick what the encoder is doing. The ringed part of the board is where to look first, and the list beside it is the order to check in.

Nothing counts

The contacts need both ends of the supply. Without VCC the pull-ups have nothing to pull CLOCK up to; without GND the contacts have nothing to close to, so CLOCK never falls. Then the cable: count from the square pad, GND, VCC, NC, BTN, CLOCK, DATA. After that, the pin numbers: CLOCK_PIN and DATA_PIN are GPIO numbers, not positions along the header.

It counts the wrong way

Not a fault. Which contact leads when turned clockwise depends on the part, and this book never claimed it. Swap count++ and count--, or swap the numbers in CLOCK_PIN and DATA_PIN.

It loses count when turned fast

A slow loop(). The polling sketch has to read CLOCK within a quarter of a cycle of each fall, and a brisk turn leaves it a few milliseconds. Why polling misses steps shows it; counting with an interrupt fixes it.

Two or four counts a click

The sketch counts more steps than the part has clicks. The state table counts four steps a cycle and divides by STEPS_PER_CLICK; if your part rests every half-cycle, set it to 2. Count one full turn against the clicks you feel.

It counts on its own

A line with nothing on it reads noise: VCC unconnected leaves CLOCK and DATA floating, and a loose CLOCK or DATA wire leaves your pin with nothing on it. If the count only flickers by one with the knob at rest, the knob is sitting between two clicks with a contact on its edge; turn it firmly into a click.

The button reads pushed all the time, or never

BTN has a pull-down: released is LOW, pushed is HIGH. A sketch copied from a pull-up button board tests for LOW and reads pushed the whole time you are not touching it. INPUT_PULLUP fights the pull-down. And without VCC the switch has nothing to join BTN to, so it never reads HIGH.