Next Steps — The KiCad Phase

What happens after this architecture is locked — schematic capture order, the footprint and CPL rotation pipeline, BOM/CPL export, the staged bring-up sequence, and the open questions that need bench answers.

The architecture is locked; the next phase is KiCad data, which was explicitly out of scope for this epic. This page is the handover: what to build, in what order, with which tools, and which gates must pass before the next step is allowed.

Fit and validate the rear controls

Board L now includes the routed JLCPCB C5446803 SW2 slide switch and rear RV1 stopped potentiometer. The rear-controls handoff gives PCB coordinates, the actual 3D render, and enclosure constraints. SW2 is included in the BOM/CPL; check both control bodies in the enclosure and check terminal fit and front lead projection. Follow the bring-up sequence, including inrush, bounce, rail decay, contact reliability and service back-power. These checks remain unperformed until hardware exists.

Schematic capture order

Capture Board P first even though it is the already-solved board — it forces the shared symbol/footprint library into existence against a circuit whose net table is already settled, so Board L's capture is not simultaneously debugging the library.

1. Board P — from the locked net table. The C1711 → C14663 100 nF swap noted on that page was applied at capture (one Extended fee removed).

2. Board L power section — J2, F1, D10, the input bulk caps, and both converters. Verify the 15 V rail on its own before any load exists downstream of it.

3. Board L LED array — the eight ballast/string blocks. Draw one string as a hierarchical sheet and instantiate it eight times rather than copy-pasting; the net table names the nets in exactly that repeating pattern.

4. Board L control — U3, RV1, RT1, the CTRL RC filter, the pad groups.

Run ERC after each stage, not once at the end.

Layout notes worth having up front

Footprint pipeline

The LCSC parts here mostly have EasyEDA footprints, and pulling them in is faster than drawing them — but it is also where the CPL rotation gotcha bites.

1. easyeda2kicad to import symbols and footprints for the LCSC parts, especially the ones with no KiCad-official equivalent (U1 STUSB4500, U2 AL8860, J1 receptacle, RV1 potentiometer and SW2 slide switch).

2. kicad-jlcpcb-tools for the BOM/CPL export rather than KiCad's built-in export — it carries a community-maintained rotation database.

3. Add explicit rotation overrides in its Corrections Manager for every EasyEDA-derived footprint family on these boards, before trusting a single generated CPL. The failure mode zudo-pd hit is a generic rule like ^SOT-23 → -90° matching an EasyEDA footprint that is already drawn in JLCPCB's pin-1 convention and applying a bogus 90° correction. On these boards that pattern threatens at minimum: Q1 (SOT-23), U4 (TSOT-23-6), U2 (MSOP-8-EP), U1 (QFN-24-EP), and U3 (TSSOP-20).

4. Check the rendered CPL against the assembly preview by eye, part by part, for every polarised or oriented device. JLCPCB's own pre-production review caught a QFN rotation problem on zudo-pd's v2 board and missed the SOT-23 over-correction on the same order — it is not a safety net.

BOM and CPL export

Use the jlcpcb-bom-generate-from-kicad skill to produce the JLCPCB-format BOM and CPL from the KiCad project. Then reconcile against the Final BOM page: every C-number must match, and the DNP lines (Board P's R17/R18 and D6/D7) plus the footprint-only pad groups (Board L's J3 and J4) must be absent from the assembly BOM, not present with zero quantity.

Re-verify stock on the four flagged lines — C571370, C500782, C2991196, C459674 — on the day of ordering, per the sourcing risks table.

docker pull --platform linux/amd64 kicad/kicad@sha256:e638b79b0321f29395a5b783e94bb9f3c73303e8da15da27b8f5cb4b67a37729

Bring-up sequence

The order here is not a suggestion. Each numbered step is a gate.

Gate 1 — Board P NVM programming, on a 5 V-only source

Write the NVM via the J2 pogo pads, then read back and verify: SNK_PDO_NUMB = 2 (PDO3 removed entirely, not merely deprioritised), PDO2 = 15 V/3 A, and POWER_ONLY_ABOVE_5V = 1. That last bit has a history of not persisting on the first write. Do not proceed until read-back is clean.

Gate 2 — Board P standalone on a 15 V charger, nothing on JOUT1

Probe the J3 debug pads:

A chip that negotiates but a switch that never turns on points at the Q1 gate network, not the STUSB4500. And do not judge Board P by downstream rails — they can legitimately read 0 V while the chip is perfectly healthy.

Two things this gate cannot measure, so don't chase them: J3 pads 6/7 (ATT/PDOK) float — the pull-ups live on Board L, so with nothing on JOUT1 these open-drain lines read garbage. Probe pad 8 (VBEN) instead. And before Gate 3, ring out the harness pin-for-pin: both ends are the same 6-pin XH housing, and a reverse-crimped harness puts 15 V onto Board L's ground with F1 on the wrong side of the fault to help.

Also measure here: the steady-state voltage across R14. This settles the open question about whether the pin-18 network draws ~32 mA continuously (0.48 W in a 100 mW resistor) or only during a discharge event. A drop near zero confirms the sense-only reading.

Use a single-port PD charger with an explicit 15 V entry in its PDO list. Every multi-port GaN charger in zudo-pd's testing failed; the one that worked was single-port — see Charger Compatibility.

Gate 3 — Board L power section alone, MCU unprogrammed

Connect Board L. Before anything else, confirm the LED array is dark. Then:

That last one is a real gate, not a formality: the safe default-OFF analysis rests on a CTRL bias-current bound that no retained fact carries, so nothing on paper closes it. If CTRL reads above 0.2 V, lower R21 and scale R20 down by the same ratio so the R21/(R20+R21) divider still delivers ~2.53 V at full duty — concretely R21 33 kΩ → 10 kΩ together with R20 10 kΩ → 3.3 kΩ, which gives 3.3 V × 10/13.3 = 2.48 V.

Gate 4 — LED array at fixed current, no firmware

Drive CTRL from a bench supply at 2.5 V. Confirm:

• Total current into LED_P ≈ 500 mA

• Per-string current across each of the eight ballast resistors — this is the measurement the whole ballast analysis exists to validate. The prediction is ±15% around 62.5 mA for a same-reel spread. If any string exceeds ~90 mA, the imbalance is worse than the datasheet's own bound and the ballast value needs raising

• Switching frequency at LED_N ≈ 440 kHz

• Board temperature after 30 minutes, at RT1 and at the hottest-looking LED

Then sweep CTRL from 0.3 V to 2.5 V (drive and measure at TP1) and confirm smooth, monotonic dimming with no flicker, buzz, or dropout — with a scope on LED_N (probe D11's anode). Record the CTRL level below which the driver enters pulse-skip / burst mode: at deep dimming the required on-time falls below the AL8860's 500 ns minimum and the converter burst-fires at an unpredictable rate. If that burst rate is under ~300 Hz at the firmware's intended floor, raise DUTY_FLOOR_Q16 above the recorded point. Any audible noise here is worth chasing before firmware exists — it is far harder to attribute once an animation is running.

Gate 5 — Firmware

No executable control firmware is in this repository. Implement PA0/ADC_IN0 absolute-position acquisition first, with suitable sample time for up to 3.35 kΩ source resistance, endpoint calibration, averaging and underside-direction inversion if required. Then bring up PWM/CTRL mapping, gamma, modulation and thermal derating. Initialize PWM off; only after valid ADC, PD-status and thermal checks, ramp toward the knob's current position. Verify power-on, watchdog/reset and rapid OFF/ON behavior.

Open the wiper connection and measure the R22/C22 nominal 10 ms discharge toward dark. This does not prove detection of all contact or wiring faults; a short to V3P3 can look like a valid high setting. Validate the fault policy and ADC settling on hardware, with the actual wheel and operating temperature.

Open questions for the bench

One pre-layout decision this design has not made

Should L1 move to the far side of the LED array? Board L currently orders the power path V15 → RS1 → SET → L1 → LED_P → ballast → strings → LED_N → U2.SW, which makes every net in the 24-LED array a switching node (LED_N 0 → ~15.5 V, LED_P ~11 → ~26.6 V at ~440 kHz). That is why the layout table above says to pour no array net as a plane — which directly contradicts the thermal budget's requirement of a generous via-stitched pour per LED pad. The design cannot satisfy both.

Reordering to V15 → RS1 → SET(= array anode) → ballast → strings → LED_N → L1 → SW_LED → U2.SW, with D11's anode on the new SW_LED node, resolves it:

• Electrically equivalent where it matters. L and the LED string are in series either way, so the inductor voltage, ripple, average current and duty are unchanged. The freewheel path becomes SW_LED → D11 → V15 → RS1 → SET → array → L1, so RS1 still carries the freewheel current and still senses average LED current — the property the AL8860's high-side sense depends on.

• The array stops switching. SET and LED_N become quiet: the residual is the ripple across the ballasts (~0.8 V pp from the nominal 0.2 A pp total, plus an unretained LED dynamic-resistance term), against ~15.5 V pp today. Only the compact SW_LED triangle — L1, U2 pins 5/6, D11's anode — swings.

• Nothing else moves. Ballasts stay anode-side, the eight cathodes still meet at one net, D11's anode still sits at U2 pins 5/6, and the commutation loop is unchanged.

Two caveats before acting. First, no retained fact records which ordering the AL8860's typical application circuit uses; fact-al8860-topology says only "hysteretic buck with integrated NDMOS and high-side current sense". The reasoning above stands on its own, but the datasheet-figure confirmation is not in the evidence registry and should be retained before this is treated as a reference-design correction rather than a project choice. Second, this is a connectivity change, which the root CLAUDE.md says the audit skills do not authorize on their own.

Procedure if adopted: edit the three NETS rows in scripts/schgen/board_l_spec.py, regenerate both boards, then re-pin the affected PROJECT_STATE records — the src-*-generator sources in component-al8860mp-13 and component-honglitronic-hl-am-2835h421w-s1-08-hr3 are sha256-locked to board_l_spec.py at revision 410bc1a, so fact-al8860-project-nets, fact-fxl-project-nets, fact-ss26-project-nets and fact-c210315-topology cannot be truthfully updated until the new spec is committed and re-hashed. validate.py also locks the AL8860 pin map in fixtures/golden/real-pin-maps.json. Do the spec edit and the evidence re-pin in one commit, or the gate goes red.

Evidence the registry is missing but the design leans on

Three numbers the design depends on are asserted in prose and retained in no fact file. None is a wiring error; all three need a source refresh (validate.py --online) rather than a hardware change.

Risks carried into the KiCad phase

References

• Lessons Carried From zudo-pd — NVM trap, bring-up sequence, CPL rotation, Extended-fee economics

• Charger Compatibility — the 15 V-PDO purchase rule and the tested-charger evidence

• Board L — the design these gates are validating

• Final BOM — what to order, and the stock lines to re-check first