HomeDeck

HomeDeck is a smart-home deck for my room: a carrier PCB for the Raspberry Pi Compute Module 4 that bolts to the back of the 7-inch Raspberry Pi Touch Display 2, with CO2 and VOC sensors, stereo speakers, two microphones, a camera and a light bar, plus the software that turns it into a voice assistant called Jarvis. I started it to learn PCB design properly, from schematic to a board assembled by a fab, and to practise product design: integrating the board, the enclosure and the software into one thing that works as a device. The first revision is on my desk and in daily use. The KiCad project, tools, enclosure CAD and assistant software are in the GitHub repository.

Overview

It does what an Echo Show does, except I know everything that runs on it. The home screen shows the time, the weather, the CO2 reading, the next calendar event, e-bikes at the nearest Bay Wheels station and what is playing. "Hey Jarvis" starts a conversation: timers, alarms, lights, music, volume and maths are matched as commands on the device without a language model; everything else goes to a hosted model. A phone app behind Google sign-in gives the same controls from anywhere, plus the camera, an intercom and presence.

Hardware

• Board: 130 x 105 mm, 4 layers, USB-C Power Delivery in (CH224K), three TPS5430 bucks, an AMS1117 3.3 V regulator.
• Compute: CM4 with Wi-Fi, 4 GB RAM and 16 GB eMMC on two Hirose DF40C sockets, flashed over USB-C with an nRPIBOOT jumper and two USB muxes.
• Display, camera, sensors: Touch Display 2 (7-inch, 720 x 1280) over DSI, Camera Module 3 over CSI, SCD40 (CO2) and BME688 (temperature, humidity, pressure, VOC) on a slotted tongue, a header for a BH1750 light sensor or an SHT4x.
• Audio and the rest: PCM5102A I2S DAC and TPA3118D2 class-D amplifier, two ICS-43434 MEMS microphones, a CH334R USB hub with USB-A and a second USB-C, ten WS2812B LEDs plus a strip header, fan, buttons, UART and expansion headers, microSD.

Software

• One Python service on the CM4 with a module per feature: voice, timers, alarms, calendar, Spotify, YouTube, sensors, weather, bikes, transit, lights, camera, presence, intercom, guest mode and more.
• A touch UI in Chromium kiosk mode with an app switcher and my own on-screen keyboard, and a phone app behind Google sign-in with secrets redacted from every API response.
• Voice: openWakeWord locally, Groq Whisper for speech to text, Groq chat with a web search fallback, Orpheus text to speech with Piper offline.

Design

The board is a KiCad 7 project I drew by hand: a hierarchical schematic of nine sheets (power, CM4, USB, video, SD, audio, sensors, UI, mechanical) and a four-layer layout, learned from the CM4 design guide and the datasheet of every part. The schematic is label style, a global label on every pin, so clicking any label shows every place that net goes. Placement is mine too, each passive next to its chip. The routing and the fab exports went through a handful of scripts, described below.

The stack-up is signal, ground, power, signal, the power layer split into planes per rail: 5V_SYS under the CM4, the 15 V input along the right edge, 5V_USB bottom left, 5V_PERIPH along the top and 3.3 V under the sensor tongue. Rules are 0.2 mm tracks and 0.15 mm clearance, down to 0.1 mm in the two CM4 fan-out areas, where every used pad gets a short stub to a small via in three staggered rows; the 0.4 mm pitch sockets are why the board is ENIG. The DSI, CSI and USB pairs are matched within 1.3 mm except the second USB-C port's data pair at 7.7 mm, which the receptacle's interleaved pads made impossible to tune automatically. That is about 2.5 percent of a USB high-speed bit, so it works, but it is the first thing I would tidy by hand.

The mechanical decision that shaped the layout: the board mounts on the display's own four M2.5 standoffs, on the 58 x 49 mm Raspberry Pi hole pattern, bottom side toward the panel. So the bottom carries only flat passives, two small transistors and the microphones; everything tall is on top. External connectors are on the bottom edge, the FPC connectors above the CM4 with the ribbons exiting toward the top, the sensors on a tongue at the left edge with two routed slots for thermal isolation, the microphones at the top corners. The first mounting was portrait; the device ended up in landscape for a thermal reason covered below.

Bill of materials

Full JLCPCB BOM and placement files are in the repository. Download the BOM (CSV).

The tools I built

KiCad has no autorouter, only its interactive push-and-shove router, and I did not want to hand-route 160 nets under a 0.4 mm pitch connector and redo them after every placement change. I also wanted rules KiCad does not know: the fan-out areas, power nets that drop to the inner planes instead of being routed, and a reserved exit direction for every fine pad. So I wrote about five scripts for the repetitive parts. route.py exports the board as JSON (pad polygons, plane outlines, per-net widths and clearances, the fourteen differential pairs, the escape strips) and hands it to router.cpp, a negotiated-congestion grid router in the PathFinder style. It is C++ because the grid is 0.1 mm over the whole board on two signal layers, about 1.4 million cells per layer. Each net is routed with A* against hard obstacles (pads, keepouts) and soft ones (other nets' copper, which only costs a penalty); nets that overlap are ripped up and rerouted with a history cost on the contested cells until the conflicts are gone. Power nets end in vias to their plane and each leg of a differential pair is pulled toward its partner. Back in Python the tracks are imported, the zones filled and KiCad's DRC run from the command line; a pass takes 20 to 40 minutes. The rest is small: a pair tuner, a ground stitcher, a clearance checker for the hand fixes, and the fab export. Five ground vias, a moved resistor and the second USB-C pair were placed by hand where the scripts stopped.

Build

JLCPCB made and assembled the boards: four layers, 1.6 mm, ENIG, two-sided "Standard" assembly because 116 of the 218 parts sit on the bottom. The BOM has 66 lines, 38 JLC Basic and 28 Extended; I picked a Basic part wherever one existed, hence three small TPS5430 bucks instead of one large one. Three parts were out of stock and swapped (the fuse, the FPC connectors and the CM4 sockets; the genuine Hirose sockets had 25 in stock and an 11-day lead). Because JLCPCB's placement preview can rotate parts, I wrote an orientation list for every assembled part with where pin 1, the cathode band or the plus mark has to sit. The tactile switches are the trap: a 90 degree error shorts the button permanently.

Bring-up followed a checklist: resistance from each rail to ground with no CM4 fitted, then the PD charger alone to check the 15 V input and 5.0 to 5.2 V on the three rails, then the module. The eMMC was flashed through the second USB-C port with the nRPIBOOT jumper, which flips both USB muxes so the CM4 talks directly to a PC. Device-tree overlays covered the DSI panel, I2C6 on GPIO 22 and 23 for the sensors, a power button on GPIO 3 and a custom audio overlay for the DAC and microphones; a serial adapter on the UART header saved time twice. In the case, two more fixes: the CM4 ran too hot, so it got the official heatsink and an SHT4x on the J12 I2C header, on a lead away from the module, now reads the room temperature; and the display ribbon was resting on the pins of the two unused button headers next to the FPC connectors, so I clipped those pins off.

Two rev A boards were assembled. Board #1 works completely after two solder-jumper changes and is in daily use: PD, all three bucks, the CM4 with Wi-Fi and Bluetooth, display and touch, camera, both sensors and the I2C header, microphones, amplifier, LEDs, fan, buttons and USB ports. Board #2 is assembled and not yet powered. What went wrong on rev A and what rev B changes:

Software

Everything runs as one systemd service on stock Raspberry Pi OS; an install.sh sets up the service, the kiosk, the audio configuration, Caddy for the phone app, DuckDNS and UPnP. The core, server.py, handles config, the module loader, an event bus, the HTTP API, the auth gate, secret redaction and the content security policy. A module is one Python file with a name, defaults, a state(), an api(), a blocking start() loop and an optional intent(text) for voice; apps on the screen register with the shell and get render, update, a home-screen tile and event hooks. Timers, conversation, air and YouTube history survive power loss, and web files hot-reload in the kiosk when their version changes.

Spotify is a Spotify Connect speaker (go-librespot) plus a Web API client, with on-device sign-in through my on-screen keyboard injected into Spotify's login pages; YouTube plays through a yt-dlp search and an ffmpeg remux into a native, ad-free player; the sensors module keeps a one-minute history and gives a spoken air report daily. Chromium shares the ALSA chain with Jarvis and Spotify so one software volume covers everything, and a watchdog restarts the browser when its shared-memory leak fills /tmp, never while the screen is being touched.

Echo cancellation was the hard part. The speaker feed is teed into an ALSA loopback card, and a helper built on WebRTC AEC3 reads the microphones and the loopback and feeds cleaned 16 kHz audio to the voice pipeline. The echo reaches the microphones 20 to 40 ms before the loopback copy, so the microphone path is delayed 60 ms. At volume 55 it removes about 16 dB of music echo; if the helper dies twice in a minute the pipeline falls back to plain capture. Later: one wake-word model on the sum of both microphones, a ten-band equaliser with a pink-noise room calibration, and 14 dB of music ducking for the whole voice turn.

Building this board taught me something about microphones in an enclosure: no matter how far out on the PCB you put them, two MEMS mics sitting near a fan and two speakers inside a closed case are hard to hear across a room. The on-board ICS-43434 pair works well within about 2 m; further away, questions often came back as "nothing said", which made Jarvis feel slow. So I added an external USB microphone, a Generalplus SF-558 on a gooseneck in the USB-A port, for talking to it from across the room. The software handles it on its own: the echo-cancellation helper got a second input with its own AEC3 instance on the same loopback reference, the voice module watches /proc/asound/cards and reopens capture when the microphone comes or goes, questions are recorded from it when present and from the on-board pair otherwise, and the wake-word stream mixes both, scaled to the USB microphone's noise floor.

Enclosure

I exported the populated board from KiCad as a STEP model and designed the case around it in Onshape, with the constraints fixed first: the board on the display's four M2.5 standoffs, bottom side toward the panel with 3 to 4 mm standoffs setting the gap, since the bottom only carries parts about a millimetre tall; the CM4, its heatsink and everything tall on the far side; every external connector on one edge. The case is a front part that holds the display behind its bezel and a back cover over the board, in landscape so the sensors sit beside the CM4 rather than above it in its rising warm air.

The board dictated most openings: the case is open at the sensor tongue so the SCD40 and BME688 read the room rather than the inside of the box, the BH1750 sits on a lead behind the bezel where it sees light, the camera sits in the bezel on its ribbon, the microphones listen up through 1 mm holes in the board and matching holes at the top corners of the case, and the speakers, fan and bottom-edge connectors each get an opening. The light is not the on-board LED bar but an external WS2812B strip on the strip header, seventy LEDs in one chain, and the software maps which of them are visible through the case. The fan in the top of the case pulls air out, so room air comes in through the side slots, past the sensor tongue on the opposite side, over the CM4 heatsink and out. The case is printed on a Bambu Lab printer in several pieces at 0.24 mm layers; the 3MF files sit alongside the KiCad project. Renders are next.

The finished device

The device in use: the home screen, the air-quality history, the apps, and a question to Jarvis.

Lights, Spotify and the app switcher from the touchscreen.

A quick question: "Hey Jarvis, what's 25 times 32?" The answer is spoken and shown large on the screen.

What I learned

PCB design

I went in knowing how to read a schematic and came out having ordered a four-layer board with a 0.4 mm pitch connector on it. Datasheets matter down to the detail: the TPS5430 wants some ESR on its output, the CM4 wants every pull-up referenced to its own 3.3 V so no pin sees voltage while the module is off, the CH334R has its crystal capacitors built in. Power needs more thought than logic: inrush into 280 uF tripped the laptop chargers, a wide inductor footprint over a plane cutout gave me an intermittent rail, and I had no test points to find either. Heat moves: a sensor above the CM4 reads ten degrees high, and in a case the CM4 needs a heatsink and an air path. And the fab's placement preview deserves a part-by-part check, because a rotated tactile switch is a permanently pressed button.

Acoustics

Microphones inside an enclosure have a short reach. However far out on the board they sit, MEMS mics next to a fan and two speakers in a closed case hear well to about 2 m and struggle beyond that. The board-mounted pair is fine for the desk; the gooseneck USB microphone is what makes talking to it from across the room work.

Coding

The software is bigger than the board. A core plus one file per feature, with an event bus and a small module contract, is what let it grow from a bench dashboard to a full assistant. I learned a lot of Linux audio the hard way: ALSA chains, dmix and softvol, loopback cards, why Chromium and PipeWire fight over a sound card, and that an empty state file for the equaliser plugin crashes every ALSA client. Measuring beat guessing: the echo canceller only worked once I measured the delay between microphones and reference, and the second wake-word model only got dropped once I measured that one instance costs half a CM4 core.

Working with AI

I used Claude's latest model at the time, Fable 5.1, to help with the build: from writing the autorouter and the other PCB scripts, to most of the code the device runs on, to custom pieces like the echo-cancellation helper that subtracts the speaker output so the microphones can still hear me while music plays. I was learning KiCad and PCB design from zero, and it was the resource I leaned on to explain datasheets I had never opened, to review the design against them before I ordered, and to work through the PD inrush and the audio chain on the bench. What it could not do was hold the board, reseat a ribbon, notice the rail that came alive when I picked the board up, model the case, or decide what the device should be. The design, the bench work, the CAD, the mistakes in the rev A table and the fixes are mine. I know the circuit well enough now to explain every block on it, which was the point.

Product design

The board was the reason I started, but most of the time went into making the pieces work together: fitting the board behind the display and inside a case that also has to hold two speakers, a fan and a camera; routing air past the sensors; deciding what the device does, what the screen shows and what a voice command should do; and finding out on the bench which of those decisions were wrong. Integrating hardware, software and the enclosure into one thing that sits on a shelf and just works is a different skill from designing any one of them.

Skills used

• Product design: integrating a board, an enclosure, a display and software into one device, and iterating on it from real use.
• PCB design in KiCad 7: four-layer stack-up with split power planes, fan-out under a 0.4 mm pitch connector, DSI, CSI and USB 2.0 pairs, a power tree from USB-C PD through three bucks and an LDO.
• Embedded Linux on the CM4: Raspberry Pi OS, device-tree overlays, ALSA, systemd, a Chromium kiosk.
• Python and C++ tooling on KiCad's pcbnew API: the grid router, the pair tuner, the ground stitching, the fab export.
• CAD in Onshape and 3D printing on Bambu Lab printers.
• Bring-up and bench debugging: rail checks, a serial console, and turning what the boards did into the rev B list.
• Fab and assembly ordering: JLCPCB BOM and placement files, part selection against stock and the Basic and Extended libraries, orientation checks in the placement preview.

What I would do differently

• Not ask for 15 V: the amplifier is the only consumer and the speakers do not need it. Rev B defaults to 9 V with inrush limiting.
• Test points on every rail where a probe reaches, and inductor footprints that are easy to solder and inspect.
• Drop the microSD slot; with an eMMC module it can never work.
• Sensors as far from the CM4 as the board allows, with the fan pulling air away from them.
• Plan for a far-field microphone from the start: a mic array in the front bezel, away from the fan and speakers, instead of relying on the on-board pair.
• Check every GPIO against the audio overlays I plan to use.
• The amplifier's mute pin with a ramp instead of its shutdown pin, and the DAC kept running between plays.
• A locking FPC connector for the display, a real PWM fan stage, and a comparator that holds the CM4 in reset until the PD contract is good.
• Skip the second wake-word instance: summing both microphones into one model scores as well at half the CPU.
• Hand-route the second USB-C port's data pair; 7.7 mm of skew should not ship in rev B.
• Keep headers out of the ribbon path, or use right-angle or low-profile headers.
• Bring the power cable in on the side of the enclosure rather than the top.