After §M6, the drive board existed and passed its electrical checks. It had exactly one job left, turning firmware into the project's signature waveform, 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. The cliff is the slip, where the foot snaps back underneath it (§M1, Figure 3). That fast fall is the flyback, which is what I call it for the rest of this chapter. The whole motor lives or dies on the shape of this one wave, and this chapter is about making it, measuring it, and the three humbling things the bench had to teach me about it.
The digital half
The waveform is born as a sawtooth lookup table in Arduino Mega firmware. Timer 4 sets the pace, and the table's values get 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]. Three channels, because the destination design is a three-legged robot running 120°-offset waveforms (§M1). Phase 1 uses one (channel 2 as of early August, and the diagnosis section below explains the move).
Each DAC0800 is an 8-bit converter, so the "smooth" ramp is really 256 little stairs, 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. Eight bits is plenty when your full-scale output is two micrometers.
The firmware default is 5 Hz. When I first read that number I assumed it was a conservative placeholder. It isn't. It is a confession about the analog half.
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 does double duty as the current-to-voltage converter (15 kΩ feedback resistor with 68 pF compensation) and then muscles the resulting waveform into the load [11, build guide]. No separate op-amp stage anywhere. The audio chip does both jobs. The rails come from the NICEPOWER bench supply, two channels wired in series to make ±15 V.
The load is the piezo stack, and electrically a piezo stack is a capacitor. Ours is 1.8 µF [9]. That single fact runs this whole chapter, because capacitors obey I = C·dV/dt, so how fast you can change the voltage is set by how much current you can pour in. The slow ramp is easy. The cliff is the hard part. Dropping 15 V across 1.8 µF in the sharp ~27 µs flyback the motor wants requires about one full 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. Ask for more frequency and the physics pushes back. Push past roughly 20 Hz and the intended sawtooth starts breaking. The peak-to-peak amplitude drops to around 5 V (my bench observation). Why amplitude is the first thing to go, when the ramp at 20 Hz is slow enough that it should barely draw current, I do not know yet. By 200 Hz to 1 kHz it has collapsed to roughly 3–5 V p-p with the flyback visibly rounded off (measured 2026-07-13) [playbook §1]. A rounded flyback is fatal for a specific reason. The slip phase needs the foot to leave fast, and a soft cliff means no slip, so no step and no motor. That's why the bench frequency is 5 Hz, why the motion is invisible to the eye, and why §M8's interferometer had to exist. One number in a firmware file, and it explains half the project.
Two things could be giving out first. It could be an RC-type bandwidth roll-off of the whole waveform, or a slew or current limit that only kills the cliff. Which one it is 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 the answer decides whether "faster" is ever an electronics upgrade or a redesign. One measurement from that month does bear on it. On 2026-08-10 the flyback at the stack's own wires came out at about 42 µs against a commanded 60 µs, which (Derived: 1.8 µF × 14.7 V ÷ 42 µs ≈ 0.63 A) means the amplifier sourced at least about 0.6 A into the stack at this rail voltage. That is a floor, not a ceiling. The board beat the command that day, so the number says what the amplifier did, not what it can do. The 27 µs the motor would like needs about 1.0 A, and whether this board can source that is exactly the question above, still unanswered.
A three-month calculation error
What follows is embarrassing, and it stays in because it's the most instructive thing in this chapter.
From April until July 17, this project's own documents said the board's output was "~30 V p-p." The BOM said it. The build guide said it. Stroke and step-size projections were computed from it. And it was wrong by a factor of two. The real output is ~15 V peak-to-peak, unipolar, 0 → +15 V [project CLAUDE.md §2, corrected 2026-07-17].
Where did 30 come 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. Nobody was lying. The number just never had a measurement underneath it, and it survived three months because it was plausible and everyone (me) kept citing documents instead of pins.
How it ended is less cinematic than a discovery scene, and I can say that with confidence because I'd forgotten the day entirely and had to reconstruct it afterward. July 17 was not a eureka. It was me trying to make the documented number real. 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 refused. It topped out at 15 V p-p no matter what the rails did. That stubborn reading, taken while chasing a number that never existed, is the "user scope measurement" in the correction log.
The log closed the case the 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]. The aftermath was cleanup: every stroke projection rescaled, a corrections log entry, and a hunt through the docs for every stale "30 V" (§M2's spec box carries the corrected value).
The chase itself probably wasn't free, either. 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 hang on the same rails. My working hypothesis for the underperforming channel 1 described below is that this session is where it got hurt [builder hypothesis, 2026-08-06]. The three-channel comparison that would test it has not been run yet, since the bench time went elsewhere (§M11). It stays a hypothesis.
The lesson I'd now engrave over any bench is that your documentation is not your instrument. A number without a measurement behind it is a rumor with good formatting, and rumors compound when documents cite documents. This one did worse than compound. It sent me to a live board with the voltage knob, hunting a spec the hardware never had, and it may have cost me a working channel. The scope reads what is on the pins and does not care what the documents say, which makes it the only honest party in the room.
What the scope caught, and what my ear caught
The catch that mattered most on screen was the frequency break described above. Ask the board for a faster sawtooth and the shape itself comes apart, amplitude first, cliff second. Watching an intended waveform visibly disintegrate as you turn one number up is the cheapest lesson in load physics I've ever gotten.
The other diagnosis tool turned out not to be on the screen at all. At 5 Hz the stack ticks audibly (loud, sharp, very noticeable, once per flyback), and that tick became an instrument. Early on, driving from DAC channel 1, the ticks were noticeably quieter. After switching the drive to channel 2, they got loud. Same firmware, same stack, different channel, different sound. Channel 1 was underperforming. I even have a prime suspect, the July 17 overdrive session from a few paragraphs up. All three channels shared those rails, but 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. Quantifying how much weaker channel 1 really is, with never-loaded channel 3 as the control, still hasn't been done. There is also a conflict inside my own record. My bench notes say the stack sits across two channel outputs ("15 volts across Ch1 and Ch2" is how my bench notes put it), which does not square with my account of simply 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. But the ear found it first, and it gives a plain-language answer to what the flyback physically is. It's the thing you can hear.
What did get measured, on 2026-08-10, is the one number that matters for every step-size claim downstream, the voltage at the stack's own wires, 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, which mattered, because that was the session where the motor would not move (§M11) and the drive had to be cleared as a suspect first. §M11 quotes the measured 14.7 V, not the commanded 15.
Current state of the electronics
The board makes a clean, honest sawtooth at 5 Hz into the hardest kind of load, 14.7 V p-p at the stack against a nominal 15, and it does so for about $50–80 in parts [11]. Its ceiling is real, 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. That is not a flaw in the build. It is the documented boundary of Phase 1.
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.