Developing an ESP32-based AI desktop companion with wake-word detection, voice interaction, animated eyes, and persistent conversation context. Pip combines embedded hardware with online AI services to research questions, generate images, and send emails, including research results and generated pictures.
ESP32Audio pipelineEmbedded firmware
Takeaways & skills
Skills developed
ESP32 and Python integration, serial communication, audio input/output, wake-word handling, display animation, persistent context, and debugging response delays. Integrating online research, image generation, and email delivery with the conversational interface.
Beyond the technical work
Breaking a complex interaction into smaller stages makes failures easier to isolate. Iterating on listening cues and response timing reinforced that usability matters alongside technical functionality—and that each fix should be checked before adding another feature.
Project notes +
Earlier Python-based prototypes integrated computer vision, sensor input, application control, and serial communication with ESP32 hardware. The standalone implementation brings the microphone, speaker, display, and conversational interface into a dedicated embedded device.
Current firmware work focuses on the transition from wake-word detection to recording, audible start/stop cues, and voice-command handling for display parameters such as eye color. Persistent memory retains conversation context across interactions; latency work targets the delay between user input and spoken output.
Beyond conversation, Pip can research topics online, generate images from spoken requests, and email results or pictures. Ongoing development connects these tools with persistent context so follow-up requests can refer back to earlier conversations and images.
02 / RESTORATIONDocumented build
FROM THE BUILD / RESTORED CLAMSHELLS
iBook G3 restoration & battery rebuild
Restored iBook G3 hardware through fault isolation, donor-board replacement, and storage upgrades. Rebuilt an eight-cell lithium-ion battery pack using spot-welded nickel interconnects and a replacement battery management board to restore charging functionality.
Hardware repairSpot weldingBMS troubleshooting
Takeaways & skills
Skills learned
Hardware fault isolation, multimeter diagnostics, SATA-to-IDE storage integration, spot welding, soldering, and troubleshooting a 4S2P battery pack and BMS. Stripped-fastener removal and precise Dremel work.
Beyond the technical work
A partial fix is a diagnostic clue, not the finish line. Repeated disassembly and a failed BMS taught me to stay persistent, use measurements to challenge assumptions, and keep donor parts available as a backup plan.
Open the build notes +
Stripped Phillips screw heads became another obstacle during disassembly. I had to use a Dremel to cut into the damaged heads so I could remove the screws and continue the restoration. Working around stubborn fasteners reinforced the value of patience, controlled tool use, and adapting when the standard approach fails.
Replaced the legacy hard drive with a 64 GB M.2 SATA SSD through a SATA-to-IDE adapter and installed a 512 MB SODIMM. After a three-beep startup fault, removing the expansion memory helped isolate the failure to onboard RAM, requiring a donor logic-board swap.
Replaced a failed optical drive, prepared bootable installation media, formatted the SSD, and installed Mac OS X before upgrading to 10.3. The repair required repeated full disassembly to access the storage and logic board.
Rebuilt the battery in a 4S2P configuration using eight 18650 cells, spot-welded nickel strips, and the original enclosure. Multimeter measurements and charging behavior pointed to a fault in the first battery management system (BMS). A donor BMS used a different revision, requiring the interconnect layout and soldered connections to be reworked before charging was restored.
Supported by the Nifty Idea Fund. Thanks to Matt Lamparter and Nathaniel Saltsgiver.
Explore the HUD, sample chat, file search, model routing, and themes. Simulated responses; no server connection.
Built a self-hosted AI system on an Ubuntu server with a Ryzen 5 3500, Radeon PRO W7700 with 16 GB VRAM, 16 GB system RAM, a 500 GB SSD, and a 2 TB hard drive. The software connects local Ollama inference and cloud model APIs to a shared browser-based voice and text interface.
UbuntuOllamaGPU memory management
Takeaways & skills
Skills developed
Ubuntu administration, GPU resource management, Ollama model integration, local/cloud request routing, API cost controls, persistent conversation context, and remote access through Tailscale.
Beyond the technical work
The project grew from hosting local models into connecting them with a usable interface. Balancing model size, available GPU memory, response time, and API spending became part of the design.
Technical architecture & build notes +
Compute and inference. The Radeon PRO W7700 provides 16 GB of GPU memory for local inference. System RAM and GPU memory are separate resource limits: selecting a model involves balancing its memory footprint against response time and the other services running on the server.
Model routing. The model setup assigns qwen3:4b-instruct to lightweight conversation, qwen3:14b to general requests, and gpt-oss:20b to coding, mathematics, and longer tasks. OpenAI and Claude APIs provide additional cloud-backed options. The routing layer brings these models into one assistant interface, with GPU-memory management and API spending limits.
Application integration. The web dashboard connects document search, persistent memory, voice recognition, image generation, scheduling, and GitHub/Netlify automation. This moves the project beyond a model chat window: the interface coordinates conversation context and tool access alongside the selected inference service.
Remote operation and interface. Tailscale connects the server to my PCs and mobile devices for remote use. The dashboard includes live system statistics, a chat console, an image gallery, settings, and a thinking view, allowing the interface and underlying model services to be managed together.
Engineering tradeoffs. The main integration problem is coordinating compute resources, model selection, and tools. Larger models require more memory, cloud requests introduce usage costs, and persistent context must remain useful across interactions. Those constraints guide the assistant’s routing and interface design.
04 / RETRO COMPUTINGAPPLE IIe
An old terminal. A new connection.SERIAL TEXT INTEGRATION
Apple IIe ChatGPT terminal
Developing an Apple IIe text terminal that connects to a modern AI service through an Apple Super Serial Card and a Windows host. The integration spans RS-232 hardware, slot-based BASIC input/output, serial-terminal configuration, and a PC-side Python/API bridge.
Serial communicationApple IIeHardware/software integration
Takeaways & skills
Skills developed
RS-232 troubleshooting, DB25/DB9 adapter integration, Super Serial Card configuration, BASIC input/output redirection, PuTTY serial testing, and separating transmit-path faults from receive-path faults.
Beyond the technical work
Getting readable text across the connection meant checking the communication path one stage at a time. Garbled output and missing responses helped narrow down configuration problems.
Technical architecture & build notes +
Hardware connection. The connection uses an Apple Super Serial Card (820-0046-B), a DB25-to-DB9 adapter, and a USB serial adapter exposed as COM3 on Windows. Card placement and the MODEM/TERMINAL jumper are part of the configuration; testing included moving the card from slot 7 to slot 4 with the jumper set to TERMINAL.
BASIC input and output. The Apple IIe routes console input and output through the selected expansion slot. During slot-4 testing, IN#4 redirected input to the serial card and PR#4 selected serial output. Testing the two directions independently made it possible to distinguish a working receive path from an unresolved transmit problem.
Measured debugging milestone. At 9600 baud, text sent from PuTTY on the PC appeared on the Apple IIe: the HELLO test confirmed PC-to-Apple reception. Apple-to-PC output still produced missing or garbled characters during those tests, including trials at 9600 and 19200 baud. Control-Reset recovered the BASIC prompt after problematic output redirection.
Host-side software. The bridge design places the Python program and AI API connection on the modern computer, while the Apple IIe handles keyboard input and text display. This separates the legacy serial interface from network access and model requests. Reliable bidirectional serial communication is the prerequisite for completing the full request-and-response loop.
Troubleshooting method. The work focuses on isolating card-slot selection, jumper and DIP-switch configuration, adapter connections, baud rate, and terminal settings. A successful receive test is treated as evidence for one direction of the link rather than proof that the entire AI terminal is working.
05 / VINTAGE APPLE RESTORATIONSiMAC G3 ELOTOUCH
Restore the hardware. Keep it compatible.DIAGNOSE REPAIR INTEGRATE
iMac G3 EloTouch restoration
Restoring a 350 MHz iMac G3 EloTouch, focusing on hardware fault isolation, legacy storage interfaces, and operating-system and driver compatibility. The project extends my iBook repair work to an older desktop with an additional touchscreen subsystem.
Component-level troubleshooting, IDE/PATA-to-SATA compatibility research, storage data and power integration, legacy Mac OS configuration, and touchscreen-driver investigation.
Beyond the technical work
Finding a replacement part is only one step. A successful restoration also depends on the connectors, power requirements, operating system, and drivers working together.
Technical architecture & build notes +
Hardware and fault isolation. The system is an iMac G3 EloTouch labeled 350 MHz. The restoration focuses on identifying faulty components and evaluating repair or replacement options, while considering storage, boot behavior, operating-system support, and the touchscreen as separate parts of the system.
SSD integration research. The storage-upgrade work investigates connecting a newer SATA SSD to the machine’s legacy IDE/PATA interface. Compatibility checks include an adapter intended to attach a SATA drive to an IDE host, the drive’s data connection, its separate power connection, and the physical fit inside the computer. These are integration requirements, not simply a choice of SSD capacity.
Operating system and touchscreen. Software planning considers Mac OS 9 and PowerPC-compatible Mac OS X alongside the drivers needed for the installed hardware. The EloTouch subsystem adds a separate compatibility task: identifying a suitable legacy driver and matching it to the operating system. Driver research remains distinct from a verified working touchscreen installation.
Related restoration techniques. My iBook work provides a documented example of the same diagnostic approach: isolating a three-beep startup fault through memory testing, replacing a donor logic board, integrating a 64 GB M.2 SATA SSD through an IDE adapter, and replacing a failed optical drive.
Battery rebuild experience. The related iBook battery rebuild used eight 18650 cells in a 4S2P configuration, spot-welded nickel interconnects, and a donor battery management board. Different BMS revisions required reworking the connections before charging was restored. That battery work belongs to the iBook restoration. Read the complete iBook build notes ↑
06 / WATCH MODIFICATIONCASIO
CASIO F-108WHC / RED FILTER · BLACK NYLON STRAP
Casio mods
Exploring optical and mechanical modifications to Casio digital watches, with a focus on display customization, component compatibility, and case assembly. The work considers how changes affect readability, fit, and everyday usability.
Display filtersComponent fitLCD optics
Takeaways & skills
Skills developing
Researching LCD optics, comparing display contrast and readability, checking component compatibility, and planning modifications around the original watch module.
Beyond the technical work
The planning process reinforces careful research and attention to detail: visual changes need to remain practical. Comparing options before buying parts helps balance appearance, usability, and cost.
Project notes +
Display-modification research focuses on contrast, light transmission, and legibility. Evaluating optical changes alongside the original LCD module helps guide customization without compromising the watch’s basic functions.
Mechanical planning focuses on component fit, case compatibility, and careful disassembly and reassembly. The goal is to customize the watch while retaining its original electronic module and practical usability.
07 / WATCH ASSEMBLYSEIKO MOVEMENTS
EXAMPLE BUILD / ROOT BEER · NH35
Seiko mods & custom watch builds
Building custom mechanical watches around Seiko movements by selecting and integrating compatible cases, dials, hands, and bracelets. The work combines component matching, mechanical assembly, and visual design.
Seiko movementsComponent selectionWatchmaking
Takeaways & skills
Skills learned
Matching movements with compatible cases, dials, and hands; mechanical assembly; checking component fit and alignment; and coordinating the finished case and bracelet.
Beyond the technical work
Small alignment and fit details affect the whole assembly. Building a watch develops patience, a methodical sequence, and the discipline to check compatibility before committing to parts.
Project notes +
Each build starts with the movement and a compatible set of components. Mechanical considerations include dial and handset fit, date-window alignment, and how the movement, crown, and case work together as an assembly.
The Root Beer mod shown here is one example: an NH35 automatic build with a black dial, brown-and-black bezel, and two-tone bracelet. Its 24-hour bezel is a styling element; this build does not have a separate GMT indication.
Designing a handheld system around original Nintendo Wii hardware, with motherboard trimming, external voltage regulation, battery integration, and display/control packaging. The design explores using a Wii U GamePad shell as the enclosure.
Board trimmingPower regulationRVLoader
Takeaways & skills
Skills developing
Power-rail planning, regulator selection, motherboard-revision research, board-trimming concepts, and mechanical packaging for batteries, controls, and cooling.
Beyond the technical work
Working within a handheld enclosure makes every design choice affect the others. The project is teaching me to divide a large build into manageable subsystems, research constraints early, and revise the plan when space or electrical requirements conflict.
Project notes +
Research and power-system planning cover Wii motherboard revisions, the OMGWTF trim, and regulation of the 1.0 V, 1.15 V, 3.3 V, and 5 V rails. Regulator options under consideration include PTH08080 and PTR08060 modules, alongside RVLoader for the portable software setup.
Integration work focuses on fitting the board, battery, display, controls, and cooling hardware within the handheld enclosure. The project remains in development, with electrical integration and mechanical packaging driving the design.
Future projects
NEXT ON THE WORKBENCH
PLANNED / NEXYS 4 FPGA
FPGA physics simulator
A planned real-time 2D physics simulator that uses the Nexys 4 FPGA to update and display a moving object. The first milestone is a bouncing ball with position, velocity, gravity, and boundary collisions; later iterations could add adjustable parameters and multiple objects.
Digital logicHardware description languageFixed-point arithmetic
Planned implementation
Separate the design into a physics-update module, display timing and rendering, and button/switch input. Use fixed-point values for motion and verify the individual modules in simulation before integrating them on the board.
Skills to develop
Synchronous logic design, HDL simulation, numerical representation, timing constraints, and hardware debugging. The broader goal is to turn a mathematical model into small, testable hardware modules and build confidence through incremental milestones.
THE PERSON BEHIND THE PROJECTS
I learn by getting hands-on.
I’m Matthew Wool, a computer engineering student at Bucknell University. My interests sit where electronics, design, and repair meet—from restoring retro computers to giving a small robot a personality.
I like projects that make me learn a new tool, figure out why something failed, and come back with a better approach.
FROM THE BUILD · PIP PROTOTYPE
