He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me.

Found in an interview with Sanjoy Mahajan, author of Street-Fighting Mathematics: The Art of Educated Guessing and Opportunistic Problem Solving, on the Freakonomics blog.

• Capture a short sample of a MIDI performance, including key velocity data.
• Quantize to a tempo set by a “tap tempo” pedal continually and dynamically throughout the capture, rather than to an LED or click track.
• Loop and play back, by default to the last tempo seen but honoring continuous “tap tempo” data from the same pedal.

Using a MIDI sequencer with these “tap tempo” features should give greater flexibility for capture and playback during a live ensemble performance than using a traditional audio looper, which requires the whole ensemble to play to the tempo recorded in the loop.

But my real motivation is to be able to play a pattern and then make gradual, multi-bar changes to the analog character of the sound without having to continue playing with one hand and turn knobs with the other.

Record a one-bar pattern on a MIDI keyboard driving a x0xb0x (or a real TB-303, if you’re filthy rich enough to have one and a DIN-sync MIDI adapter to go with it), then play it back and slowly tweak the knobs while everyone else jams on for a bit.

Am I going to find that all of this functionality already exists within the x0xb0x? (It looks like it might be close — MIDI ports; internal sequencer; variable tempo, although perhaps not that sophisticated.) Alternatively, are there MIDI sequencers that do all of this? Is this de rigeuer for every sequencer under the sun?

Ah, spare connectors to prototype, I mean; the spare connectors aren’t needed in order to get the board to boot. Ha ha.

I got mine mostly assembled last week. Like every other piece of electronics in my CupCake kit, my motherboard had missing parts — I got five extra 4.7KΩ resistors instead of the five 1.8KΩ resistors. And unfortunately, that was another part for which I couldn’t find replacements at hand — although I did end up sorting and filing a bunch more SMT components while searching.

After waiting a week for the missing resistors as the solder paste was drying out and getting crusty, I gave up and baked the thing without them. I can hand-solder the 1.8KΩ resistors onto the board when they arrive. And because they’re voltage dividers for 5V → 3.3V level conversion to the mini-SD card and pull-ups for the I²C bus — neither of which is needed for basic operation — I can even run the darn thing without them. I just need to get them on there eventually.

Crusty solder paste bakes just as nicely as gooey solder paste, by the way.

I did spend a while searching for the placement of R1 on the PC board. I eventually found it through a combination of the process of elimination and checking the schematic. As far as I can tell, the name label didn’t make it anywhere onto the silkscreen — can you spot it?

I’ve tried putting them in pockets in a three-ring binder, leaving them in the open shipping carton, and leaving them lying around on my workbench in their packages.

None of these have worked particularly well for me.

Mainframe Backup Tapes

At work, we have a large collection of “3490″ mainframe backup tapes, and they’re kept in large racks without the plastic cases the tapes ship in. In the IT environment, large sets of disks and tapes are referred to as “storage;” so the empty plastic cases and the racks the tapes go in are “storage storage,” right?

We had a few empty tape cases left, which were of no use to us and which I took home. We’ve also retired our mainframe and pruned our backup collection, so we have a number of empty racks and rack cases sitting around. It looked like an opportunity to salvage discarded materials and improve my electronic parts storage.

Tape Packages for Electronics Parts

Last night I put most of my samples into empty tape cases, and it worked quite well. At Wal-Mart I found some Avery labels that are compatible with #5366 (2/3″ x 3 7/16″, called “File Folder — White”), are ultra-opaque, are supported by the label feature in OpenOffice, and fit nicely onto the approximately 1″ x 4.25″ case spines.

Racks (Or Not)

The cases have ridged edges and stack very nicely, but I was hoping to get them into a rack for easy “random access” to individual boxes.

Unfortunately <grunt>, the racks <grunt shove> weren’t made to hold the cases <curse shove>, just the tapes <growl>, and the cases don’t fit <sigh resignation>.

I still have some of the boxes that the tapes originally shipped in, but this isn’t necessarily an improvement over just stacking the cases. They’re still sort of “latched” together in the boxes, and it’s almost more difficult to pry a case out of a full box than to balance a stack of cases whilst removing a lower one.

I’ll keep looking — hopefully there’s a rack out there that fits the cases, that someone doesn’t need any more, that I can save from the landfill, and that I get for free.

The most interesting part of the system for me is the video showing playback of motion through a building — you can clearly see where people were walking, where they ended up, etc.

This seems like a natural fit for a smart house — instead of just watching where there’s motion now, pay attention to where the motion has gone and remember that there must still be someone in that room (even if they’re not moving much now).

$10 Parallax motion sensors + blinders to narrow the cone of coverage + write open-source software for the capture and playback, anyone?

For the students, I think Gail drew the circles with pebbles in them and the younglings had to count the pebbles and write the sums of the nodes into the edges.

For adults, it’s a lot more interesting to start with the numbered edges and fill in the vertices with numbers that make the edge sums work. It’s not hard; it’s just a little bit of a twisty way of thinking.

And you have to keep your vertices balanced enough that you don’t “overflow” an edge. For example, if you started with one pebble in the upper left, then you’d have to have four in the upper right, and then zero in the lower right, and let’s just say that zero pebbles isn’t permitted. Any solvable configuration will have multiple correct answers, but they’re constrained by overflow and underflow of all the edges of the graph.

Puzzle Ball

All of which made me think that this concept could make for an interesting LED puzzle ball. Make a dodecahedron (or a smaller regular polyhedron, or even a larger geodesic shape) with LEDs along the edges and LEDs and buttons (up/down?) at the vertices.

Start it up, the LEDs flash and wink all over the place as the controller randomizes the configuration. Use the buttons to adjust the numbers at the vertices (maybe blue LEDs) so that adjacent vertices add up to the number of LEDs on that edge. As each edge is “solved,” its LEDs change from red to green. Once you have all the edges green, you’re done.

Aesthetics

Seems like it’d be coolest as a “wireframe” polyhedron rather than a solid (or solid surface).

I think I’d prefer SMT LEDs over through-hole. 3mm through-hole if absolutely necessary.

I think I’d like the edge LEDs to be strips of nine that light up fairly symmetrically from the middle out, i.e. something like

----o----              ----o----
---o-o---              ---oo----
--o-o-o--              ---ooo---
-o-o-o-o-          or  --oooo---
o-o-o-o-o         the  --ooooo--
-ooo-ooo-      boring  -oooooo--
-ooooooo-              -ooooooo-
oooo-oooo              oooooooo-
ooooooooo              ooooooooo

I’d like the whole thing to be constructed from PCBs, no separate case. There’ll need to be room for microcontrollers and/or LED drivers. Maybe instead of having the PCBs on the face of the polyhedron, have them edgewise so the PCBs’ outer edges are the edges of the polyhedron. Internally, PCBs could be held together by jumper wires soldered together at the board edges and carrying the signaling bus from one board to another.

Gameplay

I still haven’t decided whether solving the puzzle ball would be fun or merely tedious.

I remember a particular game mode in the old Merlin where you’d press buttons and all the adjacent squares would invert state, with the goal being to get all the lights on or off. I always enjoyed that game, and the way local changes impacted neighboring cells, which impacted strategy for dealing with those neighbors. I would hope that the puzzle ball would be fun in much the same way.

If each edge has nine LEDs (1 – 9) and the game is played with non-modular addition, then the average number of lit LEDs per edge will be 5.5, making the average number of lit LEDs per vertex only 2.75 — that is, on average, only a very few numbers that need to be tried at each vertex. That doesn’t sound like a very interesting game. I could increase the number of LEDs per edge to 20ish, making the average edge sum 10ish, making the average vertex 5ish, which seems okay.

Or should there be ten LEDs per edge and operate in modular arithmetic? Would that make the puzzle too easy, having more correct solutions?

However, Jeremy and I both have some issues with the feature set and the user interface of the Akai, and we’re thinking about what it would take to build a better looper — or at least, one more suited to our desires.

Feature Wishlist

Here’s what we want:

• At least 60 seconds of loop time, which would be enough to play 12-bar blues at a fairly slow tempo. The Akai’s 17.8 seconds in low-fi mode is enough for KT to do two measures of rhythm and backing vocals, but not enough to record a full chord sequence.
• Tap a Record footswitch to begin recording, tap again to end the recording and start looping. It doesn’t absolutely have to be the same switch; but some loopers out there use a potentiometer to set loop duration. We want duration to be determined by the duration of the phrase we played, as it is with the Akai.
• Independently-addressable tracks or channels. The Akai lets you discard all of your mix except your very first pass and rebuild from there. We want to have (say) eight tracks/channels in the loop mix, each with a footswitch and red/green LED. Tap Record and the next unused channel winks green and records. Tap any channel’s footswitch to put it in (green LED) or out (red LED) of the mix. Not-yet-used channels are dark.
• Independently rerecordable channels. To rerecord a channel, tap it out of the mix and immediately tap the Rerecord footswitch (which is separate from Record and a little further back or off to the side). That channel winks green and rerecords. Various loopers have varying levels of undo or redub, but none (that I’ve found) let you do this.
• Ideally have stereo recording so I can loop with the full stereo chorus effect of my analog synths.

There’s room to negotiate on the exact UI, but that should convey the feature set we’re after.

How to Build It?

John suggested using an AudioPint and Pd, and I think I may prototype this with an Arduino to run the control panel and Pd on a laptop to do the audio. But ultimately I’d like to build at least two of these in nice stage-ready stompable enclosures, and I really don’t feel like using a general-purpose OS, for a number of reasons.

It seems to me that this might be a good project for a DSP or an FPGA, but I don’t know enough to make a choice. Any suggestions? (I know I don’t need the full power of a DSP.)

What I’d love to find in one IC would be:

• Dual 16-bit ADC and DAC capable of 44.1kHz
• Address and data buses capable of addressing enough external RAM for the audio (say about 1G for stereo * 16 bits * 44100 samples/second * 60 seconds * 8 channels) without my having to worry about DRAM refresh circuitry
• A processor that I can program for the very simple, core task of summing/averaging samples from the active channels to feed to the DAC
• ~32 I/O pins to manage the control panel, and/or I²C or SPI to use offboard I/O chips
• Ideally a USB interface for uploading samples to a computer, but this would be an extremely low priority

Does such a thing exist? Is that necessarily an FPGA? Can I get a development environment for < $500 and a chip for < $30?

Survey of the Marketplace

Here’s my comparison of all the loopers reviewed at Looper’s Delight against my feature wishlist.

Gibson Echoplex

Very darn close, nice recording time, nice controls, even lets you replace part of an existing track. But unfortunately only lets you take things out of the mix via an Undo stack — LIFO.

Boomerang Phrase Sampler

Appears to stack samples and doesn’t have flexible undo/rerecord capability.

T.C. Electronic TC2290

Very pretty rack interface with lots of buttons! 4-second sample time, expandable to 64 (which would be enough if I got one with the expansion already installed; but it was made in 1986 and the expansion RAM is discontinued). Can’t find much other detail on how it works.

Lexicon MPX G2

20 seconds; layers become permanently merged into the sample at the time of recording.

DJRND3

More of a “controllerist” tool with BPM-matching stuff for doing live mixes of prerecorded tunes. Looks kinda interesting, though. Not foot-friendly — definitely a DJ tabletop piece. Oh — and it’s a prototype only that’s not manufactured.

Line6 DL4 Modeling Delay

Apparently no undo feature at all.

Red Sounds C-Loops

Another DJ tool that does tap-tempo for BPM matching; has a maximum of 32-beat sample length.

Eventide Orville

Very, very pretty family of echo/delay/FX machines. 20 seconds of looping.

Boss RC-20XL

16 minutes sampling time!!! But only one layer of undo.

Looper Construction Kit for Kyma

Looks like OS X software, so I’d need to come up with hardware to drive it, and that doesn’t suit my embedded notions.

TC Electronics D-Two

10 seconds.

Maneco Filter Eko, Nanolooper, ManecoLooper Elite, ManecoLooper, MicroLooper

Look like homebrew jobs that I couldn’t buy. 32 seconds, 16 seconds, 64 seconds, 32 seconds. Feature set is hard to tell but they definitely don’t have enough buttons to do the cut in / cut out that I want in realtime.

Akai Headrush E2

Described above, but I’ll reiterate for thoroughness: 18 seconds loop time, can only erase everything except first take.

Electro-Harmonix 16 Second Delay Reissue

Only three footswitches (and not included); loop duration is set with slide pots instead of tap to start recording, tap to stop.

Boss DD-20 Giga Delay

23 seconds, doesn’t have enough footswitches to cut tracks in and out.

Digitech JamMan

Only two footswitches.

Boss RC-50 Loop Station

Looks hot! But only has overdub (add to what’s already laid down), replace (replace EVERYTHING that’s laid down), and one layer of undo/redo.

There are a very few other products mentioned without reviews posted
yet, so I’m not being completely exhaustive.

At John’s suggestion, I’ve also submitted a query to Sweetwater asking whether they know of anything that does what we want.

The I was taking it out of my trunk to put into a “process later” pile when I noticed the front.

“X-Ray.” 60kV tube voltage. “Fine focus.” Whaaaa???

Combined with the way all the front-panel switches and knobs are bent and broken off, I’m guessing this was in one of the laboratories, some unfortunate researcher accidentally stepped in front of the beam and mutated into a creature with superhuman strength, and in the resulting chaos demolished the equipment. Since it was destroyed, now I have it. Cool!

I went ahead and disassembled it tonight. Here’s a different view of the meters:

And there’s a big pile of connectors, resistors, and lovely wires on my workbench.

Cool Rotary Switches

Here are the two rotary switch assemblies. Their knobs were broken off and their shafts bent, so they’re not working terribly well, but I’ve improved them a little.

They have circuit boards that are ganged together, with the inner shaft turning the back set of switches (of course) and the outer shaft turning the front set.

The mechanics of the assemblies are fairly intricate. You can click the picture (as always) for the full-resolution version if you want to follow along.

Clockwise from the bottom:

Every switch position is a separate trace on the PCBs, with 24 positions on the wide assembly, 12 positions on the rear part of the narrow assembly, and two sets of 5 positions on the front part of the narrow assembly. A wiper on the plastic rotor connects the PCB’s inner ring trace to each outer pad in turn.

In the upper left, you can see how the limits of rotation are set by two discs with tabs sticking out, which bolt onto the head end of the (sub-)shaft. The discs’ tabs stop against a rear-pointing tab on the head-end mounting plate, which is on the underside in this picture.

Shown at the top, the rear portion of the narrow assembly is still in good condition. It was pretty gummed up, but a few sprays of silicone lubricant got it turning nicely. The PCBs are mounted on a set of multiple threaded rods, threaded spacers, and unthreaded spacers. The rotor’s detent action is provided by the wavy disc on the back side of the mounting plate, a ball bearing sitting in a hole in the plate, and a leaf spring on the front side of the plate.

In the upper right, the front portion of the narrow assembly is okay, but the outer shaft that used to rotate it was sheared off at the base (shown immediately below it).

I had to saw the front knob off the narrow assembly’s shaft to get the assembly apart and make part of it usable. You can see that the kob appears to have been threaded onto the end of the shaft; but with a vise and a pliers, I was unable to turn it loose. The shaft had been pretty badly bent anyway, so I have no hard feelings about having to saw it off.

Idea for Rotary Switches

So I’ve actually been looking for rotary switches like this, and thinking of trying to make some myself. This unfortunately is not the form factor I need, but it shows the idea is sound.

The high school robotics team has strict rules they have to play by, and one of them is that the joysticks used to control the robots in non-autonomous mode must work like PC joysticks (I think the PIC that runs their control panel is charging and timing an RC circuit to determine the joystick position) and cannot have any supplemental power.

This wouldn’t matter, except that the linearity of the joysticks they have is poor; and with (apparently) only 8-bit sampling, there’s not as much they can do programmatically to correct the linearity as they’d like. So it takes a bit of programming effort to eliminate drift when the stick is physically centered; and then when they start to move the stick, the robot lurches into action with not much fine control over low speeds, and at high speeds is pretty much just maxed out.

Of course I assume if it were my robot, I could correct most of that in programming. Still, that’s a lot to ask of high-school kids who are already making amazing engineering accomplishments on a very tight timeline.

So Ron (of the fundraising concert, and father of the team captain) would like to figure out how to build a new joystick that abides by the letter and spirit of the rules but gives finer control over low speeds and has really significant jumps up to maximum speed only when you floor it. Obviously he wants pots with an S curve response (log taper in both directions from center), and he hasn’t been able to find that commercially, at least not that he could retrofit into a joystick.

His idea was to do it discretely — come up with some sort of switching action, then connect that to a resistor ladder. He could play with the resistor ladder to his heart’s content until he got something that “felt” right for the application — make it pluggable and let the kids swap resistors until they got a response curve they liked. And he wasn’t too worried about the robot lurching as the joystick went from step to step on the ladder — he feels that relatively few values would suffice.

If these 24-position rotary switches could fit into a joystick’s gimbal assembly, they’d be fantastic for that! Reserve the middle 3-4 positions for a broad center band to eliminate home-position drift, then have ten more positions in each direction for different speeds.

Except I’m pretty sure the gimbal assembly has little 3/4″-diameter pots right there on it, and these big PCB things just wouldn’t work. Feh.

I thought about etching my own PCBs to replace the wafers inside a couple of sacrificial pots, but I hadn’t figured out quite how to route all the wires out.

Open to suggestions here.

I like 24-hour clocks; and I’m a computer geek, so I use 24-hour time for its unambiguity. And I like the visuals of this clock — but it’s functionally useless and/or made for idiots, as the 24-hour-ness of it is strictly cosmetic. It gives you no idea whatsoever whether it’s currently 07:00 or 19:00; it just has both numbers painted on, and the hour hand will point in the general direction of both.

How ’bout a clock with a face like this — numbers spiralling inward — and an hour hand that slides back and forth end to end across its axis as it turns, so that the end of the hour hand is always touching the marking for the correct hour? At 07:00, the hour hand is still slid most of the way to the outside of the clock and its end touches the 07; at 19:00, the hour hand has withdrawn further across the center of the clock and its end touches the 19.

Of course it’d need to be done with gears; I’m not talking about an LED or LCD clock.

I’m still working on the LED calculator (original idea and most recent work) — I’ve finally got ’round to adding a rotary encoder to set the target system voltage. Now you can turn the potentiometer to set the LED brightness, turn the rotary encoder to set what voltage will be used in the ultimate LED circuit, and read the LED voltage, current, and current-limiting resistor values off the screen.

I also found the Ω in my LCD’s character matrix, so I tidied up the display a little.

And most significantly, I wrote an Arduino library for reading (multiple) quadrature encoders. The simple approach of polling them inside loop() was causing me to lose a lot of steps from the encoders; and the code to read them using hardware external interrupts (lower on the same page) only works on digital pins 2 and 3, so only supports one encoder if both pins are wired to interrupts for the highest resolution, or two if interrupting on a single pin and polling the other.

My Quadrature library uses the TIMER2 overflow interrupt service routine to poll multiple encoders rapidly and track the results, supporting as many encoders as you have room for on the digital pins. It also encapsulates all the dirty work into the library code, so using it is as simple as

#include "Quadrature.h"

Quadrature myencoder1(9, 10);  //  Connected to pins 9 and 10

loop() {
  x = myencoder1.position();
}

It still has some rough edges and it’s by no means perfect (more on that below), but it sure makes it easy to use rotary quadrature encoders. It’s available on a new Downloads page for anyone interested.

How It Works

I’ve discussed previously how rotary quadrature encoders translate the rotation of a shaft into two out-of-phase digital signals from which you can derive both the direction and speed (or steps) of rotation. If you’re not familiar with quadrature encoding and care to follow along, it might be worth a detour to the earlier post to read up on that first.

Before diving into the code, let me say that although I’ve been programming in C for about 25 years, this is my first foray into C++; and everything I’ve figured out about it, I got out of books. I welcome advice on how to write better C++ code.

Decoder

The heart of decoding quadrature is processing transitions. There are various ways of thinking of the transitions, including “on a rising (or falling) edge of pin1, check whether pin2 is high or low to determine the direction” and “on a transition of pin1, XOR pin1 and pin2 to determine the direction.” Some of these don’t even react to every transition in the state diagram (courtesy Wikipedia’s rotary encoder article):

I wanted to be able to detect every transition for the highest possible resolution — but also have the flexibility to switch between “half-stepping” and “full-stepping” to change my resolution, depending on the demands of the application and the encoder. For example, the encoder I’m using in this project has two half steps per physical detent, so I want to be able to set it to read full steps (matching the physical “clicks”) instead of half steps.

It may not be the best way, but I encoded the state change information into a pair of arrays:

const int _half [4][4] = {
    { 0, -1, 1, 0 },            //  00 -> 10 is CW
    { 1, 0, 0, -1 },            //  01 -> 00 is CW
    { -1, 0, 0, 1 },            //  10 -> 11 is CW
    { 0, 1, -1, 0 }             //  11 -> 01 is CW
};

const int _full [4][4] = {
    { 0, 0, 0, 0 },             //  00 -> 10 is silent CW
    { 1, 0, 0, -1 },            //  01 -> 00 is CW
    { -1, 0, 0, 1 },            //  10 -> 11 is CW
    { 0, 0, 0, 0 }              //  11 -> 01 is silent CW
};

Then inside my service routine, I read the current encoder values into the quadbits variable, compare it to the previous value to see whether there’s a change [*], look up the <previous, current> pair in the full-step transition table to see what to add to / subtract from the position accumulator, and then save the current encoder values for the next round through the loop.

            if (quadbits != quad->_previous) {
                int position = quad->_position +
                        _full[quad->_previous][quadbits];
                . . .
                quad->_previous = quadbits;

*   [This check isn't absolutely necessary since no-change is already encoded into the transition tables, but it shortcuts doing min/max checking if no changes have occurred.]

Right now, it’s hard-coded to use the _full[] transition table all the time, since that’s what I needed for this circuit, but it’ll be a simple matter to add another class function to select half- or full-stepping mode and choose the appropriate table here.

Calling the Decoder

Before moving it to an interrupt service routine, I tested calling the decoder function from inside the Arduino’s main loop. As I expected, when I had any other code in loop(), I lost significant numbers of steps when spinning the encoder rapidly by hand. In order to ensure the decoder was called fast enough to avoid losing steps, I moved its invocation into an interrupt service routine (ISR) for the TIMER2 overflow interrupt, which happens (in the Arduino by default) about 490 times per second.

The ISR is setup up by calling the macro ISR(<interrupt>):

ISR(TIMER2_OVF_vect) {
    Quadrature::isr();
}

The trick here is that the ISR isn’t called on a specific Quadrature object, and so doesn’t have access to the object’s private data (which pins to use, saved previous position, etc). I really didn’t want to expose all the private data as public for the ISR to access externally; and since the ISR isn’t (as far as I can tell) implemented as a function I couldn’t make it a friend function. Instead, I created a single public Quadrature::isr() function to perform the ISR tasks and called that function from the ISR.

Again, the ISR isn’t being called on a specific Quadrature object — it’s responsible for servicing all quadrature encoders that are connected. So the Quadrature::isr() function needs to have a registry of all Quadrature objects and loop through them, processing each in turn. My understanding is that the right C++ data structure for keeping that registry would be a vector; but I couldn’t find vector support in the Arduino C++ libraries, so I did it with an array. Blech.

Quadrature.h:

#define DIGITAL_PINS (13)
. . .
class Quadrature
{
    . . .
    private:
        . . .
        static Quadrature* _registry[DIGITAL_PINS];
        //static vector _registry;
};

Quadrature.cpp:

Quadrature * Quadrature::_registry[DIGITAL_PINS];
//vector Quadrature::_registry;
. . .
Quadrature::Quadrature(int pin1, int pin2):
    _pin1(pin1), _pin2(pin2), _position(0),
    _min(0), _max(0), _usingmin(0), _usingmax(0) {
    . . .
    _registry[pin1] = this;
    //_registry.push_back(this);
}

When each Quadrature object is created, I need to add it to the list of objects to be processed in the ISR. With a proper vector, I could push Quadrature object pointers onto the “list” upon creation and traverse the list in the ISR, servicing each encoder object in turn.

With an array, I should perhaps have kept a separate variable for the count of how many objects exist and put the object pointer into the next empty spot each time (much like using a vector), but instead resorted to stuffing the object pointer into the spot in the array defined by which pin is used for this encoder’s pin 1. I’m aware that the array never gets properly initialized the way it’s written now, and I’m very open to suggestions on improving this part.

So the remainder of Quadrature::isr() is a loop to iterate through however many Quadrature objects have been created and do the transition processing on each:

inline void Quadrature::isr(void) {
    int q;

    for (q = 0; q < DIGITAL_PINS; ++ q) {
        Quadrature *quad;

        if (_registry[q]) {
            quad = _registry[q];
            . . .
            //  transition code goes here
        }
    }
}

ISR Caveat

One last thing about the ISR: TIMER2 is used for Arduino PWM output, and my ISR doesn't interfere with that because the PWM is done in hardware and the ISR is done in software. However, my ISR will overwrite any ISR that may already have been attached to TIMER2, if the program is using multiple timer-driven libraries.

The last time I wrote ISRs was on the Apple ][ and Commodore-64, where the convention was to check the current interrupt vector before installing your ISR, stuff the current contents into your own code, and (if non-zero) jump to that location at the end of your ISR. That way if an ISR was already installed, you'd chain to it after your ISR code finished, and it would still be executed.

I can't quite see how to do that on the Arduino, though, at least not without rewriting the ISR() macro, and I'm not clear enough how chip-specific that macro is to be ready to tackle it. Another possibility would be to create an ISR registry system and persuade all ISR authors to use the ISR registry to insert their ISR into the registry-managed chain. Neither of these is able to force compatibility with non-cooperating code, though; and of course neither addresses the issue of different ISR-using libraries wanting to change the timer speed. Perhaps caveat library user really is the best that can be done.

Object Constructor

Here's the constructor to create a new object:

Quadrature::Quadrature(int pin1, int pin2):
    _pin1(pin1), _pin2(pin2), _position(0),
    _min(0), _max(0), _usingmin(0), _usingmax(0) {

    pinMode(pin1, INPUT);
    pinMode(pin2, INPUT);
    digitalWrite(pin1, HIGH);           //  activate internal pullups
    digitalWrite(pin2, HIGH);

    _previous = _readpins();            //  read initial position

    TIMSK2 |= (1 << TOIE2);             //  enable timer 2 overflow interrupt

    _registry[pin1] = this;
    //_registry.push_back(this);
}

The Quadrature::Quadrature() constructor uses an initialization list (I think I’m using the correct terminology) to initialize the values of most of the private variables. It then sets the two encoder pins as inputs and activates the internal pull-up resistors, reads in the initial encoder pin values, enables the TIMER2 interrupt, and (as seen before) registers this new object onto the list to process in the ISR.

Remaining Code

I haven’t touched on the minimum and maximum capabilities yet — you can call myencoder.minimum(foo) to set the minimum value of the encoder’s position to foo and myencoder.maximum(bar) to set the maximum to bar. You can also call oldmin = myencoder.minimum() to read and save the current minimum setting, with a corresponding function for reading the max; and you can call myencoder.nominimum() to turn off minimum (or maximum) processing if you don’t want it in a particular section of code.

I’m trying to facilitate a program using an encoder for multiple functions — for example, first selecting a mode (“Audio Function”), then selecting a parameter (“Balance”), then selecting a value for that parameter (-5 to 5). Each of these may require different minima and maxima for its list, all operating at different times on the same encoder object.

Most of the rest of the code is housekeeping. It’s a bit long to paste the whole thing in here; but if you’re interested in looking it over and offering improvements, download a copy, look over Quadrature.h and Quadrature.cpp, and post comments below.

Using the Quadrature Library

Encapsulating code into libraries makes using that functionality so much easier; and encapsulating multiple encoders into objects is a really good use for object-oriented programming. The pertinent sections of my LED calculator code have simplified to this:

#include "Quadrature.h"
Quadrature supply(8, 10);

. . .

void setup() {
  . . .
  supply.minimum(0);
  supply.maximum(120);
  supply.position(50);
}

void loop() {
  . . .
  resistor = (float) supply.position() / 10 / led_current;
  . . .
}

I’m dividing the rotary encoder’s value by 10 to serve .1V increments, and initializing it to run from 0-120 (0-12V) and to start at 50 (5.0V). I’m also thinking about creating a setup menu for the LED calculator user to program in their preferred minimum, default, and maximum supply voltages for the target system, and saving those in the Arduino’s internal EEPROM.

Future Enhancements

Enhancements to the Quadrature library:

• Clean up the _registry[] array code — make it work more like a vector, as discussed above.
• Support changing between half- and full-step modes.
• Add an “acceleration” mode that works like mouse drivers — increment/decrement with a larger step size when you’re turning the encoder fast. (Right now, it takes me multiple turns to get from 5V to 12V. It should take a single fast turn to get close, and some slow fine-tuning to dial in the exact desired value.)
• Add a function to change the timer speed, hence the frequency of checking the encoder in the ISR. Right now the code works well for hand-driven rotary encoders, but would drop steps horribly for encoders attached to motor shafts, wheels, etc.
• Create a subclass to return speed and direction, rather than position?

Enhancements to the voltage-selection code in the LED calculator:

• Allow the user to change the minimum, default, and maximum target voltages, as mentioned above.
• Allow the user to program in a set of favorite voltages (e.g. 3.3V, 5.0V, and 12.0V) and make the rotary encoder select from the list rather than dialing in arbitrary voltages?

LED Calculator Next Steps

I have an enclosure for the calculator that I’m not thrilled about (it’s taller than I like) but which will work, and an LCD that fits the case. I need to order rotary encoders from Digi-Key so I can build an exact prototype of what I want to offer kits for, and then I’m ready to lay out the PCB and make one!