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”
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.
Many 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.
[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”