After §M6, the drive board's one remaining job was to turn firmware into a sawtooth that ramps slowly from 0 up to 15 volts and then falls off a cliff. The slow ramp is the stick, where friction drags the slider along, and the cliff is the slip, where the foot snaps back underneath it (§M1, Figure 3). I call that fast fall the flyback from here on.
The digital half
The waveform starts as a sawtooth lookup table in Arduino Mega firmware. Timer 4 sets the pace, and the table's values are written out over the Mega's parallel ports (PORTA, PORTC, and PORTL, one port per channel), so all three DAC channels update on the same tick [11, build guide]. There are three channels because the final design is a three-legged robot running 120°-offset waveforms (§M1), but Phase 1 uses one (channel 2 as of early August, and the diagnosis section below explains the move).
Since each DAC0800 is an 8-bit converter, the ramp is really 256 small steps, each about 59 mV tall at full scale (Derived: 15 V ÷ 256). At the stack's end of the chain, 59 mV works out to motion steps under 8 nanometers each (Derived: 2.0 µm stroke ÷ 256), which is far below anything the mechanics can feel. The firmware default is 5 Hz. When I first read that number I assumed it was a conservative placeholder, but it is set by what the analog half can handle.
The analog half
Each DAC0800 outputs a current rather than a voltage. In the Liao design, the current flows into a TDA2050, an audio power amplifier chip that works both as the current-to-voltage converter (15 kΩ feedback resistor with 68 pF compensation) and as the stage that drives the waveform into the load [11, build guide]. There is no separate op-amp stage anywhere. The rails come from the NICEPOWER bench supply, with two channels wired in series to make ±15 V.
The load is the piezo stack, which is electrically a capacitor, and ours is 1.8 µF [9]. A capacitor obeys I = C·dV/dt, so how fast the voltage can change is set by how much current can go in. The slow ramp is easy, but dropping 15 V across 1.8 µF in the sharp ~27 µs flyback the motor wants requires about one ampere (Derived: I = C·ΔV/Δt = 1.8 µF × 15 V ÷ 27 µs ≈ 1.0 A, flyback time per first_motion_playbook.md §2, set by the TDA2050's current into the stack).
At 5 Hz, the amp keeps up, with full 0→15 V amplitude, a sharp cliff, and a clean slip. Past roughly 20 Hz the intended sawtooth starts breaking, and the peak-to-peak amplitude drops to around 5 V (my bench observation). I do not know yet why amplitude is the first thing to go, even though the ramp at 20 Hz is slow enough that it should barely draw current. By 200 Hz to 1 kHz the amplitude has fallen to roughly 3–5 V p-p with the flyback visibly rounded off (measured 2026-07-13) [playbook §1].
A rounded flyback stops the motor, because the slip phase needs the foot to leave fast, and a soft cliff means no slip, so no step. This is why the bench frequency is 5 Hz, why the motion is invisible to the eye, and why §M8's interferometer had to exist.
The breakdown could come from an RC-type bandwidth roll-off of the whole waveform or from a slew or current limit that only kills the cliff, and which one is the cause is still open. The playbook has a test for it (sweep frequency while scoping the stack, watch what degrades first). August's bench days went to the motion diagnosis instead (§M10, §M11), so the test is still on the list, and its answer decides whether "faster" is ever an electronics upgrade or a redesign.
On 2026-08-10 the flyback at the stack's own wires came out at about 42 µs against a commanded 60 µs, which means the amplifier sourced at least about 0.6 A into the stack at this rail voltage (Derived: 1.8 µF × 14.7 V ÷ 42 µs ≈ 0.63 A). That is a floor, not a ceiling, because the board beat the command that day. The 27 µs the motor would like needs about 1.0 A, and whether this board can source that is the question above, still unanswered.
A three-month calculation error
From April until July 17, this project's own documents said the board's output was "~30 V p-p." The BOM and the build guide both said it, and stroke and step-size projections were computed from it. That figure was wrong by a factor of two, which is embarrassing. The real output is ~15 V peak-to-peak, unipolar, 0 → +15 V [project CLAUDE.md §2, corrected 2026-07-17].
The 30 came from the supply. The board runs on ±15 V rails, and somewhere early on, the 30-volt span between the rails got written down as the signal amplitude, and then every later document inherited the number from the earlier ones. The number never had a measurement underneath it, and it survived three months because it was plausible and I kept citing documents instead of measuring the pins.
I had entirely forgotten the day this error was corrected and had to reconstruct it afterward. On July 17 the stack wasn't moving, I was testing anything I could think of, and one of the attempts was brute force, stepping the bench supply's two series channels up to 30 V each (a ±30 V, 60-volt span across rails designed for ±15 [builder, confirmed 2026-08-06]), trying to push the output toward the 30 V p-p the documents promised.
The output topped out at 15 V p-p no matter what the rails did. That reading is the "user scope measurement" in the correction log, and the log settled the matter that same day with three agreeing sources: the scope reading, the build guide's own power section ("±15V for 15V p-p output"), and the original paper's manuscript [project CLAUDE.md §2, corrected 2026-07-17]. After that, every stroke projection was rescaled and the docs were searched for every stale "30 V" (§M2's spec box carries the corrected value).
The brute-force attempt itself probably wasn't free. That 60-volt span sits far beyond the DAC0800's 36 V absolute maximum [design_notes §18 via CLAUDE.md §2], and all three channels share the same rails. My working hypothesis for the underperforming channel 1 (described below) is that this session is where it was damaged [builder hypothesis, 2026-08-06]. The three-channel comparison that would test it has not been run yet, so it stays a hypothesis.
What the scope caught, and what my ear caught
On screen, the catch that mattered most was the frequency break described above. The other diagnosis tool turned out to be the sound of the stack. At 5 Hz it ticks audibly (loud, sharp, very noticeable, once per flyback), and that tick became an instrument.
Early on, when I drove the stack from DAC channel 1, the ticks were noticeably quieter. After I switched the drive to channel 2, with the same firmware and the same stack, they got loud. Channel 1 was underperforming, and the ear found it first.
My suspect is the July 17 overdrive session. Channel 1 was the one wired to the stack at the time, and my best guess is that some chip in its path took the damage [builder hypothesis, 2026-08-06]. An ear is not an oscilloscope, and quantifying how much weaker channel 1 is, with never-loaded channel 3 as the control, still hasn't been done.
My bench notes say the stack sits across two channel outputs ("15 volts across Ch1 and Ch2"), which does not square with my account of moving the drive from channel 1 to channel 2. Until I trace the leads I cannot say which is right, and the lead-to-channel wiring and polarity stay open.
What did get measured, on 2026-08-10, is the voltage at the stack's own wires, the one number that matters for every step-size claim downstream. It was 14.7 V p-p, with the ≈42 µs flyback described above [run log 2026-08-10]. The tick that day was loud and sharp and the stack vibration was palpable under a fingertip. That mattered because it was the session where the motor would not move (§M11) and the drive had to be cleared as a suspect first.
Current state of the electronics
The board makes a clean, accurate sawtooth at 5 Hz into the hardest kind of load, 14.7 V p-p at the stack against a nominal 15, for about $50–80 in parts [11]. The board has a frequency ceiling, and I have measured where it starts even though I have not identified what causes it. Amplitude falls off past tens of hertz, which caps speed until the current source improves, and this is the documented boundary of Phase 1 rather than a flaw in the build.
Whether that sawtooth actually moves anything is a question about friction, preload, and mechanics (§M9). Seeing the answer at all is a question about instruments, and that comes first.