Logs

Build Log

Chronological notes from the build — decisions made, things discovered, steps taken.

2026-05-09 — Project started

Initial research into LED tech stack. Confirmed goals: ~100,000 LEDs, RGBWW for cathedral warmth, animated effects + ambient modes. Agreed on terminology: LEDs (individual emitters), pixels (addressable units), nodes (SmartReceiver boards).

Confirmed architecture: Falcon F48V5 + SmartReceivers over Cat6 differential signal.

2026-05-11 — 3D model analyzed

Analyzed Rhino model (exported from Blender). Confirmed key measurements:

  • Footprint: 36.5m × 28.3m, 19.2m tall
  • 8 scaffold towers, 11.9m tall
  • All 4 main spires identical: 7.31m tall, 1.76 × 1.53m base
  • Front spires sit higher (base at 11.9m) than back (base at 8.0m)
  • 20 corner spirelets in two height groups
  • Rose window: 4.877m diameter at Z = 3.1–8.0m

2026-05-13 — Rose window SVG + LED path

Exported petal framing and tracery from Rhino, converted to combined SVG. John drew the LED tape path in Illustrator (petal-combined-path-v3.svg). Path measured at 8,372mm / 502 LEDs per petal.

Established airplane-seat cell naming convention: rows 1–7, a/b/c columns. 14 cells per petal. Per-cell LED breakdown complete.

SRx4 ↔ F48V5 compatibility confirmed by David Pitts (pixelcontroller.com).

IP65 decided (not IP67/68) — Alex: silicone sleeves trap heat on playa.

2026-05-14 — Rose window spec finalized; wiki launched; zones defined

Rose window:

  • Petal count revised to 18 (16 installed + 2 spares)
  • Strip length 900cm per petal; 162m total (18 strips). BTF-Lighting max is 5m — options are single 9m custom-length strip (preferred, find supplier) or 2×5m rolls joined per petal.
  • Connector standard settled: BTF-Lighting IP65 threaded barrel, 22mm, 3-pin throughout. Chosen over JST SM (playa failure history), GX16 (only IP55), and WEIPU SP13 (no pre-terminated strip options). (Superseded 2026-05-19 — see xConnect below.)
  • 24V throughout with Mean Well SD-150B-5 buck converter (24V→5V, 30A) at rose window. ⚠️ Must be B suffix — D suffix is 72–144V input and won’t work with 24V supply.
  • PSU candidate: Mean Well HLG-240H-24 (240W, 24V, IP65/67, wide input 90–305V AC). First unit ordered for NYC lab testing; becomes part of playa distribution.

Zones confirmed:

  • Rose Window — spec complete
  • Spires & Canopy — WS2811 globe nodes, 24V RGB (not RGBW)
  • Arches — SK9822 SPI vs WS2811 24V, undecided
  • Interior Orbs — ~26 beach-ball-scale glowing spheres inside structure; likely DIY polycarbonate globe + WS2811 nodes, approach TBD
  • Corner Spires — 20 corner spirelets as translucent cones with RGB inside, approach TBD

Wiki:

  • Launched at the-gothic-folly.github.io/documentation/
  • GitHub org: The-Gothic-Folly, repo: documentation

2026-05-17 — Zones SVG illustration; rose window chip changed to GS8208 24V

Zones illustration: Created a projected 2D illustration of all LED zones using a Python OBJ projection script (drawings/obj-to-svg.py). Per-zone OBJ files exported from Blender; projected through the Blender camera matrix into a single SVG with one named layer per zone. Rotated 92.16° CW to make the front spire vertical. Published to wiki as PNG at 2× resolution.

Zone names updated: “Small Spires” → “Corner Spires”; “Spires & Canopy” split into “Main Spires” + “Canopy”; “Interior Arches” added as distinct zone.

Rose window chip changed: Alex wants full 24V standardization — no buck converter, one voltage throughout. WS2813 is 5V-only. Investigated 24V alternatives at 60/m and found GS8208: constant-current driver gives 1 pixel per LED at 24V. GS8208 retains dual data line (breakpoint resume) and uses WS2811 protocol. Heat is the tradeoff (~75W/m at full white). Test strips ordered before bulk purchase. Buck converter (Mean Well SD-150B-5) removed from BOM.

2026-05-18 — Rose window finalized: WS2815 12V, dedicated PSU

Third iteration on rose window strip choice:

  1. WS2813 5V → needed 5V buck converter
  2. GS8208 24V → 24V IP65 not available from US suppliers; heat also a concern (~75W/m)
  3. WS2815 12V ✅ — WS2813’s successor, dual data line retained, 60px/m, widely available on Amazon Prime from BTF-Lighting

Key insight: the F48V5 differential signal to SmartReceivers carries no power. Each SmartReceiver has its own power input. So the rose window SRx4 runs at 12V while all other SmartReceivers run at 24V — no converter anywhere, each zone is self-contained.

Rose window PSU: 2× Mean Well HLG-320H-12 (320W, 12V) in parallel.

Ordering: 36 rolls WS2815 IP65 60/m 5m from BTF-Lighting (2 rolls per petal × 18 petals), SRx4, 2× HLG-320H-12, connectors, Cat6, thermal tape.

2026-05-19 — Connector standard changed to xConnect; pixel map + simulator complete

Connectors: Rose window LED vendor (Ray Wu’s Store) pre-terminates strips with xConnect from the factory. Standardized on xConnect 3-pin throughout (V+, GND, DATA).

Pixel map: Cell polygon boundaries extracted from OBJ geometry. 224 addressable cells (16 petals × 14 cells each). Airplane-seat naming confirmed. Universe map defined: 16 universes (1 per petal), 14 RGB cells each = 42 channels, hub → rim order.

Simulator: Browser-based rose window preview with cell-fill mode, 8 effects, WebSocket live mode. sACN relay (Node.js) receives from TouchDesigner or xLights and forwards to browser.

xLights custom model: rose-window.xmodel generated — 80×80 grid, 224 pixels at actual circular positions.

2026-05-20–21 — xLights pipeline end-to-end confirmed; Custom Model injection

xLights → sACN → relay → browser simulator confirmed working with all 16 rose window petals live. Key discovery: xLights Matrix model sends pixels linearly (all 224 on Universe 1), not per-petal as expected. Relay updated with dual-mode auto-detection.

Custom Model (true circular pixel positions) injected directly into xlights_rgbeffects.xml via inject-custom-model.py. Each pixel assigned correct universe/channel matching physical petal wiring — what you build in xLights is exactly what plays on playa.

2026-05-23 — End-to-end testing; show-builder package rebuilt

Full xLights simulation walkthrough from scratch. Several instruction gaps found and fixed: drag-folder-to-Terminal tip for relay path, rose-window-standalone.html moved to package root, xlights-show/ folder added to zip. Pipeline confirmed working with a non-technical user following the updated guide.

2026-05-24 — Arches pixel map + simulator; quad arches; SmartReceiver correction

Arches: LED run paths exported from Blender as OBJ tube meshes. Python script extracts centerlines, distributes pixels at 5 LEDs/pixel (WS2811), maps to universes 17–31. Main arches (5), mini arches (10), quad arches (24 faces across 6 groups) all mapped. Pixel positions in show-builder/pixel-map/.

Simulator: arches-sim.html updated — all 15 main/mini arches and 6 quad arch clusters, with perspective projection per zone. Wired to relay for live sACN.

SmartReceiver correction: SRx1 = 4 outputs (not 1 as previously assumed). SRx2 = 8 outputs. All three arch zones now use 1× SRx2 each instead of 5× SRx1 — reduces boards from 15 → 3 and Cat6 runs from 15 → 3.

xLights lesson: When using multiple controllers in xLights, channel assignment is per-controller-space, not based on universe number. Single Ethernet_ controller with all 21 universes declared explicitly (AutoSize=0) is the correct approach.

2026-05-25 — SK9822 ruled out; WS2811 confirmed; spires + canopy mapped; 48 universes fit

Strip type confirmed: David Pitts (pixelcontroller.com) confirmed SmartReceivers only support 3- or 4-wire pixels (no clock line). SK9822 requires a clock line — incompatible. All arch zones use WS2811 24V 30/m throughout.

Spires + canopy: Main spires (4), corner spirelets (20), and canopy (6 runs) all mapped from Blender OBJs. Universe 42–45 for spires, universe 46–47 for corner spirelets + canopy, universe 48 for interior orbs.

F48V5 fits everything: 48/48 outputs used for the full installation. No second controller needed (held in reserve if orb count grows). Total: ~3,659 addressable pixels, ~22,800 physical LEDs.

2026-05-26 — 3D layout simulator launched; xLights 3D positioning; 8-strand spires

3D simulator: cathedral-3d-sim.html built with Three.js — all zones rendered in real cathedral coordinates. OrbitControls, zone toggles, live sACN from relay. Rose window shows actual 224 cell polygons. Canopy drawn with parabolic sag. Published to wiki.

xLights 3D: All 70+ xLights models assigned real WorldPos/Scale values matching physical cathedral positions. Coordinate mapping: WorldPosX = catZ (left-right), WorldPosY = catY (height), WorldPosZ = −catX (depth, front-facing).

Spires updated to 8 strands: Hunter revised main spires from 6 → 8 globe-string strands. Pixel count per spire: 112 (8 strands × 14 pixels). All spire JSON, models, and simulators updated.

2026-05-27 — xLights left-right mirror fixed; 3D House Preview scaled 10×

Root cause of all mirroring issues: WorldPosZ = catX (positive) put the back of the cathedral facing the default xLights camera, so every left-right effect was visually flipped. Fix: WorldPosZ = -catX. Cathedral now faces the camera correctly with no rotation. Column-ordering fixes from the prior session were consistent with this change and didn’t need reverting.

House Preview scale corrected: added WORLD_SCALE = 10.0 to all WorldPos/Scale scripts. Cathedral now spans ~360 units in the preview — proportionate and navigable.

2026-05-29 — TouchDesigner full-cathedral package

TD starter package extended from rose window only (universes 1–16) to all zones. New generate-td-all-zones.py reads all pixel-map JSONs and outputs all-pixels-positions.csv (3,567 rows, universes 17–48) with physical and normalized (x/y/z_norm) coordinates. New generate-full-patch.py builds a complete TD component with GLSL effect, Script CHOP, and sACN Out for all non-rose-window zones. Both files added to the show-builder package.

2026-06-02 — First rose window petal installed (P01); architecture decisions

Physical install: First petal (P01) installed on the rose window frame. Actual LED count: 517 (estimated 501). Minor cell-boundary shifts from physical install caused a cumulative offset — slightly more LEDs fell into some cells than designed. petal-config-v2.json updated with actual P01 cell segment data as the new default. Pixel positions resampled from 502 → 517 via arc-length interpolation. All downstream data (simulator, xLights models) regenerated and published.

Effects distribution: Cathedral-specific effects (.xsq files) will be distributed à la carte from the wiki — not bundled in the main show-builder package. New effects can be added anytime without requiring a re-download.

LED remapping workflow: When physical installs differ from designed layout, update the pixel-map JSON directly. Show designers submit .xsq files (not .fseq); re-rendering against the updated model automatically produces correct channel output for the current physical layout.

Decisions & Rationale

Key choices made during the build, and why.

IP65 for all LED strips

Decided: 2026-05-13

Alex reports that silicone-sleeved strips (IP67/68) trap heat on the playa — the sleeve doesn’t allow air circulation, leading to overheating. We’re using IP65 silicone-coated strips throughout. The coating protects against dust without trapping heat.

WS2815 12V for the rose window (supersedes WS2813 and GS8208)

Decided: 2026-05-18

Decision history:

  1. WS2813 5V (2026-05-13) — dual data line, great chip, but 5V-only requiring buck converter
  2. GS8208 24V (2026-05-17) — only 24V chip at 60px/m; 24V IP65 not available from US suppliers; heat issue (~75W/m) also a concern
  3. WS2815 12V (2026-05-18) — ✅ final choice

WS2815 is WS2813’s direct successor: dual data line (breakpoint resume), 60/m, 1 pixel per LED, widely available from BTF-Lighting on Amazon Prime. It runs at 12V natively — a purpose-designed voltage for the chip, with half the heat of GS8208 at 24V (~32W/m vs ~75W/m).

No converter needed: the rose window gets its own dedicated 12V PSU (Mean Well HLG-320H-12). The F48V5 differential signal to the SRx4 is power-independent, so the rose window can run at 12V while every other zone runs at 24V.

xConnect connectors throughout (supersedes BTF-Lighting threaded barrel, 2026-05-19)

Decided: 2026-05-19

The rose window LED vendor (Ray Wu’s Store) pre-terminates strips with xConnect from the factory. Standardizing on xConnect throughout for consistency.

Standard: xConnect 3-pin throughout (V+, GND, DATA).

Previous choice (BTF-Lighting IP65 threaded barrel 22mm) was superseded when the vendor pre-terminated with xConnect, removing any need for adapters at the rose window.

Mixed voltage: 12V rose window, 24V everywhere else

Decided: 2026-05-18

The rest of the installation runs 24V (spires, arches, canopy, orbs). The rose window runs 12V on a dedicated PSU. F48V5 differential signal carries no power — each SmartReceiver has its own power input — so each zone is self-contained at its native voltage. No converter anywhere.

WS2811 24V for arches (SK9822 ruled out)

Decided: 2026-05-25

SK9822 was originally under consideration (a Sonic Runway artist recommended it for its clock-line stability). We emailed David Pitts at pixelcontroller.com to confirm compatibility.

His answer: SmartReceivers only support 3- or 4-wire pixels — no clock line. SK9822 requires a two-wire SPI signal (data + clock), so it’s simply incompatible at the hardware level.

This also clarified why WS2811 + SmartReceivers is the right approach regardless of cable length: the F48V5 sends a robust differential signal (RS-485 over EtherCon) to a SmartReceiver mounted right at the base of each arch. The SmartReceiver then drives the pixels over a short hop — well within the 20–40ft limit. WS2811 handles that fine.

Result: All arch zones (main, mini, quad) use WS2811 24V 30/m. SK9822 removed from BOM.

F48V5 + SmartReceiver architecture

Decided: 2026-05-09

One Falcon F48V5 as the central controller. SmartReceivers at each zone cluster, connected via Cat6 differential signal. Confirmed F48V5 ↔ SRx4 compatibility with David Pitts (pixelcontroller.com), 2026-05-13.

Zones illustration: Python OBJ projection, not Blender render

Decided: 2026-05-17

Needed a clean 2D illustration of all LED zones for the wiki. Two approaches tried:

  1. Blender Freestyle SVG Exporter — produces line art from the 3D model. Hard to color individual zones independently.
  2. Python OBJ projection (drawings/obj-to-svg.py) — reads per-zone OBJ files, projects vertices through the Blender camera matrix, produces an SVG with one named <g> layer per zone. Full control over color, fill, opacity, layering. Chosen approach.

The Gothic Folly — Burning Man 2026