A Rotary Encoder: How Hard Can It Be?

As you may have noticed, I’ve been working with an STM32 ARM CPU using Mbed. There was a time when Mbed was pretty simple, but a lot has changed since it has morphed into Mbed OS. Unfortunately, that means that a lot of libraries and examples you can find don’t work with the newer system.

I needed a rotary encoder — I pulled a cheap one out of one of those “49 boards for Arduino” kits you see around. Not the finest encoder in the land, I’m sure, but it should do the job. Unfortunately, Mbed OS doesn’t have a driver for an encoder and the first few third-party libraries I found either worked via polling or wouldn’t compile with the latest Mbed. Of course, reading an encoder isn’t a mysterious process. How hard can it be to write the code yourself? How hard, indeed. I thought I’d share my code and the process of how I got there.

There are many ways you can read a rotary encoder. Some are probably better than my method. Also, these cheap mechanical encoders are terrible. If you were trying to do precision work, you should probably be looking at a different technology like an optical encoder. I mention this because it is nearly impossible to read one of these flawlessly.

So my goal was simple: I wanted something interrupt driven. Most of what I found required you to periodically call some function or set up a timer interrupt. Then they built a state machine to track the encoder. That’s fine, but it means you eat up a lot of processor just to check in on the encoder even if it isn’t moving. The STM32 CPU can easily interrupt with a pin changes, so that’s what I wanted.

The Catch

The problem is, of course, that mechanical switches bounce. So you have to filter that bounce either in hardware or software. I really didn’t want to put in any extra hardware more than a capacitor, so the software would have to handle it.

I also didn’t want to use any more interrupts than absolutely necessary. The Mbed system makes it easy to handle interrupts, but there is a bit of latency. Actually, after it was all over, I measured the latency and it isn’t that bad — I’ll talk about that a little later. Regardless, I had decided to try to use only a pair of interrupts.

Continue reading “A Rotary Encoder: How Hard Can It Be?”

Benchtop Lathe Gets An Electronic Leadscrew Makeover

The king of machine tools is the lathe, and if the king has a heart, it’s probably the leadscrew. That’s the bit that allows threading operations, arguably the most important job a lathe can tackle. It’s a simple concept, really – the leadscrew is mechanically linked through gears to the spindle so that the cutting tool moves along the long axis of the workpiece as it rotates, allowing it to cut threads of the desired pitch.

But what’s simple in concept can be complicated in reality. As [Clough42] points out, most lathes couple the lead screw to the spindle drive through a complex series of gears that need to be swapped in and out to accommodate different thread pitches, and makes going from imperial to metric a whole ball of wax by itself. So he set about building an electronic leadscrew for his lathe. The idea is to forgo the gear train and drive the leadscrew directly with a high-quality stepper motor. That sounds easy enough, but bear in mind that the translation of the tool needs to be perfectly synchronized with the rotation of the spindle to make threading possible. That will be accomplished with an industrial-grade quadrature encoder coupled to the spindle, which will tell software running on a TI LaunchPad how fast to turn the stepper – and in which direction, to control thread handedness. The video below has some great detail on real-time operating systems on microcontrollers as well as tests on all the hardware to be used.

This is only a proof of concept at this point, but we’re looking forward to the rest of this series. In the meantime, [Quinn Dunki]’s excellent series on choosing a lathe should keep you going.

Continue reading “Benchtop Lathe Gets An Electronic Leadscrew Makeover”

Encoders Spin Us Right Round

Rotary encoders are great devices. Monitoring just a few pins you can easily and quickly read in rotation and direction of a user input (as well as many other applications). But as with anything, there are caveats. I recently had the chance to dive into some of the benefits and drawbacks of rotary encoders and how to work with them.

I often work with students on different levels of electronic projects. One student project needed a rotary encoder. These come in mechanical and optical variants. In a way, they are very simple devices. In another way, they have some complex nuances. The target board was an ST Nucleo. This particular board has a small ARM processor and can use mbed environment for development and programming. The board itself can take Arduino daughter boards and have additional pins for ST morpho boards (whatever those are).

The mbed system is the ARM’s answer to Arduino. A web-based IDE lets you write C++ code with tons of support libraries. The board looks like a USB drive, so you download the program to this ersatz drive, and the board is programmed. I posted an intro to mbed awhile back with a similar board, so if you want a refresher on that, you might like to read that first.

Reading the Encoder

The encoder we had was on a little PCB that you get when you buy one of those Chinese Arduino 37 sensor kits. (By the way, if you are looking for documentation on those kinds of boards, look here.; in particular, this was a KY-040 module.) The board has power and ground pins, along with three pins. One of the pins is a switch closure to ground when you depress the shaft of the encoder. The other two encode the direction and speed of the shaft rotation. There are three pull-up resistors, one for each output.

I expected to explain how the device worked, and then assist in writing some code with a good example of having to debounce, use pin change interrupts, and obviously throw in some other arcane lore. Turns out that was wholly unnecessary. Well… sort of.

Continue reading “Encoders Spin Us Right Round”

Hackaday Links: Sunday, April 28th, 2013


Another week has gone by and we hope you’ve been happily hacking away in your underground lairs. If not, here’s some inspiration that didn’t quite make it to the front page this week:

[Razr] used a CFL ballast to replace the mechanical one in his fluorescent tube light fixture.

To make the drawers of his workbench more awesome [Rhys] used the faceplates from some servers.

This week saw some changes in the hobby PCB market. Looks like BatchPCB is being sold to OSH Park starting May 1st. [Thanks Brad]

[Rich Olson] shouldn’t have any trouble getting out of bed now that his alarm clock literally shreds cash if he doesn’t shut it off.

We faced the same problem as [Kremmel] when we first got a Raspberry Pi, no USB keyboard. We bought one but he simply hacked his laptop to work. [Thanks Roth]

You may remember that post about a self-propelled snowboard. Here’s a similar project that uses a screw-drive system.

And finally, if you need help reading a quadrature encoder from a microcontroller this lengthy technical post is the place to look.

Estimate Velocity Using Quadrature Encoder Data

quadrature-encoder-velocityMany motors offer a quadrature encoder that give feedback on whether, and in which direction, the motor shaft is moving. But if you’re clever about analyzing the data you can use a quadrature encoder to estimate motor velocity. [Jason Sachs] makes the case that it’s fairly easy to get this wrong. Lucky for us he has carefully laid out his process of extrapolating velocity from the two edge-trigger data sources.

The process starts with reading from the encoder. Many chips have peripherals that will interface with a rotary encoder, but hardware lacking that built-in helper can still be used by monitoring pin-change interrupts. Once connected samples are taken over time and the rest is left to the quality of your algorithm.

What can this velocity data be used for? That’s up to you. But we can think of a couple of projects. It may be useful in a spinning POV display like this FPGA-based beauty. You also find quadrature encoders in exercise equipment. Knowing the velocity will help if you’re building your own computer to replace what came with that Stairmaster.

[via Reddit]

Game Of Chance Built As A Red Bull Creation Entry

[Tom Bourke] wrote in to show off the game of chance which was built for this year’s Red Bull Creation contest. The project was completed with the help of the Wausau Collaboration Center, a Hackerspace in Wausau, Wisconsin.

He does a great job of showing off the game in the clip after the break. Near the bottom of the device is a hard drive platter which each player can spin to test his or her luck. [Tom] used a max485 chip to turn the leads for the hard drive motor into a quadrature encoder. This input is monitored by the Bullduino board, which puts on a light and sound show during the spin. The LEDs that surround the display are individually addressable (probably the same LED strings as this wall display) and cycle trough different colors based on the rotational speed of the patters. The large seven segment display provides a readout for the random number that is generated. Roll a ten and you win! We guess you need to make the rest of the game up yourself, but this could easily be used as a 16-sided die (or less).

Continue reading “Game Of Chance Built As A Red Bull Creation Entry”