A Pocket Rolling Stone, Part 3: The PCBs Arrive, and the Ball Comes Back

Tue, 13 Oct 2026 00:00:00 +0000

The boards arrived. I plugged them in, flashed them, tested them: they work. After the separate modules, the wires, and the small enclosure wrapped around the first prototype, the rolling stone now has a dedicated printed circuit board.

In Part 1, I described the physics and the I2S audio build. In Part 2, I moved to an H-bridge and a version I actually put in a handheld enclosure. This time, the adventure runs between the schematic, the JLCPCB order, and the return to the bench. The ball is still virtual; the electronics giving it weight in the hand are becoming rather more tangible.

From modules to a dedicated board

The first builds answered one question: could I recreate this illusion with fairly simple, modern electronics? Once that worked, another question followed: how could I make something reproducible without rebuilding the whole assembly by hand each time?

The PCB did not emerge from a single drawing. The design went through several revisions, from A1 to A7. An early correction in A1 involved the JST connector polarity: a tiny detail on a schematic, and an essential one on the real board. Later work was as much about fit as electronics, placing connectors and buttons where they would remain accessible through the enclosure and arranging the components within the available space.

The clearest change came with A7, prepared on September 13: components on both sides. The board shrank from A5’s 32 × 120 mm to 32 × 85 mm, roughly 29% less area. It uses four layers and is 1 mm thick. Those millimetres matter when the whole point is to hold the object and tilt it in your hand.

One of the boards received, viewed from the radio-module side. Dimensions in the text refer to the documented A7 PCB, rather than measurements taken from this photograph.

Ordering an assembly, not just copper

I ordered the boards from JLCPCB. That stage needs more than a circuit-board file: the Gerbers, bill of materials, and placement files all have to describe exactly the same assembly.

The A7 export specified 89 assembled components, with 52 on the top and 37 on the bottom, across 37 BOM lines. The complete design contained 103 footprints, which is a different count from the components included in the assembly order.

Before that export, the electrical and design-rule checks reported zero errors, with no unrouted connections. But automated checks do not tell the whole story. Reviewing the JLCPCB assembly preview on September 17 revealed a rotation issue: U9’s leads appeared at 90 degrees to the pads. U5 and the four MAX chips also needed pin-number checks. I had to examine how the manufacturer interpreted the placement file, not just whether the PCB was correctly routed.

That is a useful lesson from this order: keep the schematic, board, and actual submitted files together, and inspect the assembly preview. The placement file is as much a part of the hardware as the copper.

Another view of the boards received, with the USB-C port and buttons accessible. After the manufacturing files, there is finally hardware to try.

Back on the bench: actual results

The October 9 tests brought A7 through flashing and into operation. Telemetry showed the physics loop running between 1,999 and 2,000 Hz, with IMU readings at approximately 1,733 Hz. The simulation now runs at about 2 kHz, compared with the 1 kHz loop in the earlier builds described on this blog.

But getting the firmware running also exposed a hardware weakness: I had been too optimistic about the power supply design. The board experienced brownouts: the supply voltage fell low enough for the ESP32 to reset. A device that restarts can soon look healthy again, so simply seeing the simulation running was not enough. I needed a way to tell whether a test had introduced another power-related reset, even if I had missed it happening.

That led to a small persistent diagnostic in the A7 firmware. At startup, it reads the ESP32’s reset reason with esp_reset_reason(). Every boot increments a boot counter; only ESP_RST_BROWNOUT increments the brownout counter. Both are saved in non-volatile storage through Preferences, so a restart does not erase the evidence.

The firmware prints the totals over serial, exposes the brownout count in its status output, and flashes the LED red three times after a brownout reset. That gives me both an immediate signal on the device and a record to compare before and after an experiment. It counts resets attributed to brownouts by the chip, rather than measuring every voltage dip.

With that diagnostic in place, the later checks were easier to interpret: the brownout counter stayed at 9, with no new brownout resets recorded during that run, while the audio-drop counter stayed at zero. That was encouraging within the tested conditions. It did not establish that the underlying power-supply limitation was resolved; it gave us a way to track the problem while working out where the design needed more margin.

Letting the IMU measure the actuators

The PCB was designed from the outset with four independently driven channels, to accommodate the full Drake range: LFi, LF, MF and HF. The aim was to combine their different strengths for a broader usable frequency range, more output where needed, and more flexibility in the effects we could render. Measuring their response would tell us how to distribute the signal to make use of that potential, within the available power budget.

That architecture also leaves room for different builds. The same PCB can support versions with one, two, three or four actuators, populating only the amplifier chips and associated components needed for the chosen channels. A simpler version would not need a new board layout or all four amplifier circuits assembled. The two-actuator prototype is one configuration of that platform.

For these first measurements, LFi and HF were fitted. The TITAN Drake datasheet gave us the starting point: an impact-oriented LFi and a higher-frequency HF, with nominal peak-acceleration frequencies of 65 and 160 Hz under the manufacturer’s 100 g test conditions. That suggested complementary roles, but did not tell us their response in this assembly. The immediate task was to characterize this pair; the same approach could then guide other combinations on the four-channel board.

The useful trick was already sitting on the PCB: the IMU used to measure the tilt could also measure the vibrations we generated. In a dedicated bring-up mode, the firmware drove one actuator at a time through 40 frequencies from 20 to 500 Hz, recorded a silent baseline, and measured acceleration on all three axes. It picked out the response at the driven frequency using the actual sample timestamps—a lock-in measurement—rather than treating every movement of the board as useful output. It also examined harmonics where the sampling rate allowed it, then drove the pair with matching and opposite polarities to see how their vibrations combined.

This was still a proof of concept, with the actuators held in place by zip ties, rather than a finished mechanical assembly. That improvised mounting helps explain why the curves are not particularly clean: the IMU sees the actuators through the fixings and the mechanical path to the sensor. The useful result at this stage was showing that we could measure and compare their responses with the electronics already on the board.

In that setup, the October 8 sweep at 0.25 full-scale drive put the measured LFi peak near 69 Hz, and the HF peak near 238 Hz. These are observations from this temporary assembly, not new specifications for the bare actuators or a controlled comparison with the datasheet. They give us an initial view of how the pair behaves together. A better mechanical assembly, followed by another sweep, is needed before using those curves as a firm basis for tuning.

October 8 proof-of-concept sweep, 20–500 Hz, 0.25 full-scale drive per active channel. The actuators were held by zip ties; the uneven curves include that temporary mounting. These measurements demonstrate the method and will need repeating with a better assembly.

The analysis also explored a crossover: splitting a desired signal between the two actuators while accounting for their sensitivity, how they add together, and the available drive headroom. It recommended a 330 Hz crossover for that run. With this temporary mounting, that is an exploratory setting to revisit after rebuilding and measuring again. Only LFi and HF were fitted; the other two amplifier channels remained unused.

Why the rolling stone needed a texture mode

Once the board worked, the question changed from “does it vibrate?” to “does it feel like a ball?” The classic rolling waveform conveyed motion, but its repeated shape lacked the finer, higher-frequency detail I expected from a metal ball moving inside a plastic tube. Turning up the gain would make that same limited signal stronger. It would not add the missing texture—and the power-supply trouble was another reason not to reach for amplitude first.

TEXTURED keeps the rolling physics and changes how that motion becomes vibration. Instead of repeating only the original waveform, it moves the virtual ball over a spatial roughness profile and uses that excitation to drive damped resonances. Linking roughness to distance travelled makes the pattern follow the ball’s motion: changing its speed changes how quickly it encounters those details. The LFi carries the low-frequency body and impacts; the HF adds the finer layer. Classic rolling remains available for direct comparison.

On A7, body resonances at 90, 280 and 430 Hz are supplemented by detail generated at 700, 1,800 and 3,600 Hz in the 48 kHz audio path. These last numbers describe the generated signal: our actuator sweep stopped at 500 Hz, so it did not establish how much of those higher bands reaches the hand. I liked the resulting TEXTURED sensation, but separating a promising perceptual result from a measured mechanical response gives the next experiments a clear purpose.

Why keep measuring—and why turn it into a game?

The Tauri companion connected over USB makes the iteration easier to interpret. Seeing the simulated ball while feeling it helps separate a wrong motion model from a poor vibration rendering. Mode and gain controls make comparisons quicker, while diagnostics let me check whether a change in sensation coincides with a timing or reset problem.

MARBLES asks a different question: can the vibrations convey what is inside without showing it? The intended game is to shake the device like a matchbox and guess how many balls it contains. Hidden rounds use zero to five identical virtual 10 mm metal balls, with the count and positions concealed until reveal. Wall impacts and collisions between balls become clues. It gives the simulation a purpose beyond watching an animation: finding out whether the contact events are distinct enough to interpret through the hand.

That is also why the remaining work matters. More response measurements would tell us which synthesized details actually survive the actuators and mounting, so we can shape the signal rather than spend power on ineffective output. More supply margin is needed to preserve convincing impacts without triggering resets. The enclosure and grip need attention because they are part of the vibration path to the hand. Finally, repeatable comparisons—including gentle rolling, which initially felt too muted—will help distinguish “more vibration” from a more convincing ball. The PCB works; now it gives us a platform for asking those better questions.

The project page brings the series together. The public ESP32 Ball repository contains the firmware and companion application for the earlier builds.