Pixelpine

PixelPine — a 7 cm PCB Christmas tree with 240 charlieplexed LEDs

KTE Project 1 · design-for-manufacture study · rev A · 2026-09-23

A chubby, cute, 70 mm tall PCB tree covered in 240 warm-white 0603 LEDs on a 2.12 mm grid. The LEDs are charlieplexed on 16 pins of a $0.13 Puya PY32F003 (Cortex-M0+, 64 KB flash) with software PWM. It runs from USB-C and slots into a PCB stand fin. The tree is a character, Pine, whose job is showing light shows. He's bad at it: he daydreams, naps, gets grumpy and gets excited to show you things. You interact with him through the capacitive star, which senses tap, pet, press, a front-and-back squeeze and tickles. The product firmware runs on the first boards and matches the simulator frame for frame (firmware/pixelpine/). Landed cost ≈ €3.2 at 1 000 pcs, €2.0 at 10 000 pcs; suggested shelf price €12.90.

Try Pine in your browser: machmar.github.io/pixelpine (the animation simulator).

Front	Back

Deliverables

Key numbers

LED arrangement

The 240 LED positions are a fixed 2.12 mm grid, but which anode/cathode pair sits at which position is a free choice, and it decides whether the board can be routed at all. The first version interleaved the pairs (anode = n mod 16), which leaves every one of the 480 LED pads as an island of its own, and Freerouting stalled with 76 connections still open after 87 minutes.

The 45° LEDs form a "brick" lattice with only ~0.55 mm between neighbouring pads. If two neighbouring pads are on the same line net, a tiny F.Cu bridge joins them for free, so a net can be a few big copper islands instead of 30 loose pads. hardware/scripts/optimize_leds.py (simulated annealing, C core in optimize_leds.c) arranges the 240 pairs for exactly that: 480 separate pads became 141 islands, only the links between islands need real wiring, and the board routes on 2 layers in about 2 minutes (it also stopped needing the 4 layers that the old arrangement was thought to need). The result is hardware/led_assignment.json, committed; geometry.py reads it, so the schematic, PCB, simulator map and firmware tables all follow from it. Every LED keeps the same orientation; the optimiser can also turn LEDs round by 180° (--flip) for ~15 % fewer islands, but that wasn't needed.

Side effect: neighbouring LEDs now sometimes share an anode line (17 % of the LED pairs closer than 3.2 mm, against 6 % with the old interleaving), so a lit blob loads some scan phases harder than before. The numbers are in docs/power-and-connectivity.md.

Regenerating the hardware

Since 2026-10-01 the board is finished by hand in KiCad (GND pour, extra vias). build_all.py would regenerate it from the scripts and drop those edits, so it now stops unless you pass --regenerate. For order files run export_gerbers.py (KiCad's Python) and export_fab.py; see hardware/production/README.md.

Everything in hardware/ was generated from one geometry module, so it stays consistent:

python hardware/scripts/build_all.py

geometry.py (outline, LED grid, charlieplex map from led_assignment.json) → gen_footprints.py → gen_sch.py (+ ERC, netlist check) → gen_pcb.py (KiCad's bundled Python) → route.py (Freerouting, ~2-5 min; if connections stay open it routes again from scratch, up to 4 runs) → DRC and parity → 3D renders → JLC BOM/CPL. It also refreshes simulator/led_map.js, so the simulator always shows the real LED positions. After editing the outline, run python hardware/scripts/geometry.py --search and paste the new pitch into GRID_PITCH, then python hardware/scripts/optimize_leds.py (needs a C compiler, 10–20 min) to re-arrange the LEDs for the new grid. The firmware's per-LED tables come from the same map: python firmware/pixelpine/gen_tables.py, then python firmware/pixelpine/build.py flash builds and programs a board, and python firmware/pixelpine/test/compare.py checks the firmware against the simulator.

Open items before ordering

Order files are ready: hardware/production/README.md. At order time, check LCSC stock for the 240 LEDs per board and look at the LED polarity and U1 pin 1 in JLC's placement preview.

1. Firmware: done on the first board (2026-11-03): it powers up at 4.97 V with no short, flashes through a J-Link (firmware/flash/) and runs Pine (firmware/pixelpine/). Still open: touch thresholds measured on one board and one hand (measure a batch); the EMC worst-case and production-test firmware builds.
2. Room light can't be sensed on rev A: in a full charlieplex every LED has an anti-parallel twin, so no LED can work as a photodiode, and Pine stays in "lights on" mode. Rev B fix at no cost: leave one LED unpopulated (firmware/pixelpine/README.md).
3. Hover isn't detectable with the star electrode (a finger 1 cm away is below the noise); tap, pet, press, squeeze and tickle work.
4. No whole-tree touch on rev A: the LED lines can pick up the mains hum a finger carries, but only on a mains-tied supply (strong on a laptop, weak on a wall charger, nothing on a powerbank), so it was dropped after five experiments (firmware/pixelpine/README.md). The star is the touch control.

Done: PCB routed on 2 layers (LED arrangement optimised for it, DRC clean), manufacturer name, address (Jehličková 240, 240 24 Stromečkov: made up for the school project, replace it with the registered address for a real product) and e-mail on the product, U1 and J1 placement orientation checked, MCU choice final (PY32F003F18P6, kept over the cheaper F002A for firmware-update headroom).