Control Research: Knob Candidates

Panel potentiometer vs rotary encoder for the lamp's modulation-parameter knob, with an honest JLCPCB-availability check.

Context

The lamp needs a physical knob the user turns to control the fire/wave modulation (see modulation-algorithms for what it might control). Two classic approaches: a panel-mount potentiometer read by the MCU's ADC, or a rotary encoder read as a quadrature digital signal. The source issue requires the circuit to stay JLCPCB-only — this page checks real stock, not just "what's the standard part for this."

Option A — Panel-mount potentiometer (analog, into ADC)

How it works: a 3-terminal resistive element; the wiper voltage (a fraction of the rail reference) is read directly by one ADC channel. Absolute position — the knob's physical angle always corresponds to the same reading, even after a power cycle. Familiar, simple firmware (read_adc() -> brightness), no interrupts or edge-counting needed.

JLCPCB availability — checked honestly, and it's thin. The classic panel-mount pot (metal bushing + threaded shaft for panel mounting through an enclosure, the part a hobbyist would reach for — e.g. the ubiquitous WH148) has zero stock across every SKU variant in the local JLCPCB DB:

This isn't a one-off gap — the broader Resistors > Potentiometers, Variable Resistors category (23,518 parts) is dominated by PCB-mount trimmers meant for screwdriver calibration, not hand-turned panel knobs:

Honest verdict: a true panel-mount potentiometer with a knob-ready bushing and shaft is not realistically sourceable from JLCPCB's SMT/THT assembly stock — the DB confirms zero stock on the standard part family. Getting one would mean sourcing off-JLCPCB (e.g. Bourns/Alps via Digi-Key/Mouser), which breaks the JLCPCB-only constraint from the source issue. The 3296/3362-style trimmers are well-stocked but are calibration trimmers, not knobs — usable only as a fallback behind a panel cutout with a small custom-fit knob press-fit onto the adjustment slot, which is a marginal user experience and not recommended as the primary path.

Option B — Rotary encoder (quadrature, digital)

How it works: two digital outputs (A/B) that a rotating shaft toggles out of phase; the MCU counts edges (interrupt or timer input-capture) to track relative position, and optionally a third pin for an integrated push-button (many encoder parts bundle a click-to-push switch on the same shaft). Endless rotation — no mechanical end-stops — and typically better tactile "feel" (detents) for a UI control than a pot.

JLCPCB availability — good. Switches > Rotary Encoders has 2,976 parts, and the common EC11 family (the de facto hobbyist/consumer-electronics standard, THT, panel-mountable via a threaded metal bushing + nut, same mechanical mounting style people expect from a "knob") is well stocked:

None of these are Basic/Preferred tier (all Extended, ~¥470 one-time fee per unique part on JLCPCB's assembly service) — but stock is in the thousands across multiple SKUs, versus zero for panel pots. This is the honest recommendation for a JLCPCB-only BOM.

Trade-offs vs a pot:

• No absolute position — firmware must track a running count and clamp/wrap it in software; after a power cycle the knob's physical angle doesn't correspond to anything until the user turns it (mitigated by picking a sane default on boot, see control-safety).

• Needs 2 GPIO (A/B) rather than 1 ADC channel, plus interrupt or polling logic instead of a single read_adc() call — slightly more firmware complexity, but well-trodden ground (every MCU family has quadrature-decode examples).

• Mounting: EC11's metal bushing + nut is the same panel-mounting mechanism people expect from a knob, which matters for the future 3D-printed enclosure — a designed-in panel cutout + nut is straightforward, unlike adapting a trimmer's screwdriver slot.

Recommendation

Rotary encoder (EC11 family) is the honest JLCPCB-only pick — real stock, real panel-mountable hardware, endless rotation fits a "speed/depth/brightness" style control well. A panel potentiometer would be the more common electrical choice (simpler firmware, absolute position) but isn't realistically available in JLCPCB's own stock for the panel-ready form factor; using it would require breaking the JLCPCB-only sourcing constraint from the source issue.

Questions the architecture pass must answer

• Confirm final acceptance of the JLCPCB-only constraint's implication: does the project accept the encoder's lack of absolute position, or is off-JLCPCB pot sourcing acceptable for this one part (breaking the stated constraint)?

• Does the chosen encoder need an integrated push-button (for a mode-select gesture, e.g. short-press to cycle between speed/depth/brightness assignment)? None of the three shortlisted EC11 SKUs above were confirmed to include one from the DB description alone — verify against the actual datasheet before BOM lock.

• Pull-up strategy for the A/B lines: external resistors vs MCU-internal pull-ups (all three MCU candidates in mcu-candidates have internal weak pull-ups, likely sufficient given the encoder's low switching speed).

• Debounce approach: firmware-timer debounce vs a small RC filter on A/B — either works at knob-turning speeds; architecture pass picks based on GPIO budget and firmware complexity preference.