Due Uno — two Arduino Uno R3+ boards. The decision to use two was the single biggest structural change in the whole V2.0 design. Get info and Uno R3 boards HERE!

Every good project needs a plan. The decision to apply to present at TSB V turned out to be one of the best things that could have happened to this project — not just as a deadline, but as a discipline. Putting together a formal proposal meant sitting down and writing out, clearly and honestly, exactly what was wrong with the current system and exactly how I intended to fix it. It was a planning exercise as much as a pitch, and it sharpened everything.

The issues were familiar — I'd been living with them for years. The display was limited and hard to read. The physical buttons were imprecise. The motor mounting wasn't rigid enough, allowing belt tension to vary. And controls still required a hand on the box. But the deepest problem was architectural: the Arduino was being asked to do too much at once. Running the motor, managing the display, reading the controls, executing the FX programs — all of it competing inside a single programming loop. The result was a system that worked, but worked with compromises baked in.

Part of my goal was to make this buildable by anybody in the world — so I wanted as many components as possible to be simple, off-the-shelf solutions.

With the proposal written and accepted, the next step was practical: sourcing parts. In the past I had often manufactured components myself — the mechanical parts especially — and sometimes that's still the right approach. But this project had a different ambition. If other people were going to be able to build this, it needed to be achievable without a workshop full of specialist tools. So I turned to Amazon and started searching. I bought a range of components — some that would be needed immediately, others that I was planning ahead for — motors to experiment with, mounting hardware, display modules, control inputs. Having thought about this for so long, I had a clear enough picture in my head of what was needed.

The biggest single change — the one that unlocked everything else — was the decision to move from one Arduino to two. A more complex system with a richer display, more input options, and more FX programs would simply be too much for the single-Arduino architecture. The loop-based nature of Arduino programming means that everything shares the same cycle time — add too much, and the motor suffers. Slower, noisier, less precise. That wasn't acceptable.

The solution was elegant in its simplicity. One Arduino would handle only the motor — driving it, running the FX programs, keeping everything smooth and silent. The second Arduino would handle everything else — the display, the controls, the user interface. It would then pass a compact set of numbers to the motor Arduino via a serial connection: program number, speed, direction, whatever was needed. Clean, simple, separated.

The choice of connection protocol was deliberate too. The two-wire I²C serial bus built into Arduino is not just simple — it's essentially universal. Countless consumer electronic devices use the same protocol, which meant that choosing it now kept the door open for integrating other devices later. A Bluetooth module. A phone app. A remote connection over the internet. Even sensor-based touchless control. None of that was in scope for the immediate build, but designing with it in mind cost nothing and kept the possibilities open.

So that was Goal One: get two Arduinos talking to each other reliably. Everything else would follow from there.