For those of us whose interests lie in radio, encountering our first software defined radio must have universally seemed like a miracle. Here is a surprisingly simple device, essentially a clever mixer and a set of analogue-to-digital or digital-to-analogue converters, that can import all the complex and tricky-to-set-up parts of a traditional radio to a computer, in which all signal procession can be done using software.
When your curiosity gets the better of you and you start to peer into the workings of a software defined radio though, you encounter something you won’t have seen before in a traditional radio. There are two mixers fed by a two local oscillators on the same frequency but with a 90 degree phase shift, and in a receiver the resulting mixer products are fed into two separate ADCs. You encounter the letters I and Q in relation to these two signal paths, and wonder what on earth all that means.
Human input devices are a consumable on our computers today. They are so cheap and standardised, that when a mouse or a keyboard expires we don’t think twice, just throw it away and buy another one. It’ll work for sure with whatever computer we have, and we can keep on without pause.
On earlier machines though, we might not be so lucky. The first generation of computers with mice didn’t have USB or even PS/2 or serial, instead they had a wide variety of proprietary mouse interfaces that usually carried the quadrature signals direct from the peripheral’s rotary sensors. If you have a quadrature mouse that dies then you’re in trouble, because you won’t easily find a new one.
Fortunately there is a solution. In the intervening decades the price of computing power has fallen to the extent that you can buy a single board computer with far more than enough power to interface with a standard USB mouse and emulate a quadrature mouse all at the same time. This was exactly the solution [Andrew Armstrong] took to provide a replacement mouse for his Atari ST, he used a Raspberry Pi as both USB host and quadrature mouse emulator (YouTube link) through its GPIOs.
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.
As a contrast to the first MIDI controller, this would be a stripped-down build, with just three faders, LEDs for eye candy, a pair of pots for gain control, and a hard disk surrounded by six anti-vandal buttons. The hard disk is the star of the show, acting as a rotary encoder.
When manually spun, the hard disk generates a few phases of sinusoidal waves. The faster you spin it, the higher the amplitude and frequency. These signals are far too weak to be sampled directly by a microcontroller, and for digital control – as in, MIDI – you don’t need to read the analog signals anyway. These signals were turned digital with the help of an LM339 quad comparator. With two of these comparators and signals out of the hard disk that are 90 degrees out of phase, quadrature encoding is pretty easy.
The software for this MIDI controller is based on the OpenDeck Platform, a neat system that allows anyone to create their own MIDI controllers and devices. It’s also a great looking board that seems to perform well. Video below.