Good News First
Today the good half of the loop closed. Reach into the A-10C's virtual cockpit, put the mouse on the console knob on the Light Control Panel, and turn it — and the LED on my bench dims with it. No separate control, no fudge factor. The jet says dim, the hardware dims.
That's the whole point of the thing, and it's now confirmed rather than assumed. DCS exports the console lighting value, it comes down over DCS-BIOS, it goes through a gamma curve, and it comes out the other side as 12-bit PWM at 30.5 kHz on a GPIO pin. Turning it with the mouse matters more than it sounds: it proves the export path on its own, with no physical hardware involved in the reading. The brightness genuinely comes from the simulator.
30.5 kHz is not an arbitrary number. Anything slower and a phone camera picks up rolling dark bands across the panel, because a rolling shutter exposes each scanline for tens of microseconds. People film their pits. A panel that looks fine to the eye and terrible on video is a panel that gets a bad review, so the switching frequency is set high enough that it can't happen.
The gamma curve is the other half. Perceived brightness runs roughly as the 2.2 power of duty cycle, so a straight linear map makes the bottom half of the dial do almost nothing and then jump. With 4096 levels and a correction curve, the dim end is where most of the visible change lives.
And then there's the knob
In a finished panel, the cockpit dimmer knob is a physical potentiometer sitting under the customer's hand. On the bench that's a B10K (a 10 kΩ linear pot) with three jumper wires hanging off it. It is the cheapest, dumbest component in the entire build, and it is the one causing today's problems.
Two of them, and they look almost identical from the outside.
Problem one: it isn't dividing
A pot is a voltage divider, not a variable resistor. All three legs have to be connected for it to behave: one outer leg to the 3.3 V rail, the other outer leg to ground, the wiper in the middle feeding the analogue input. Turn the shaft and the wiper slides along a resistive track between the two rails, picking off a voltage somewhere between them.
Leave one end open and the maths stops working, but not in a way that announces itself. An ADC input draws essentially no current, and no current through a resistance means no voltage drop across it. So with one track end disconnected, the wiper doesn't read "somewhere in between". It sits at whatever rail it can still see, regardless of where the knob is pointing. The symptom is a raw reading pinned near full scale, never quite reaching zero, with occasional dips that land somewhere different on every sweep. That last part is the tell: intermittent readings mean intermittent contact, and pot legs are thick, short and seat badly in a breadboard.
The related trap is which rail you take the top from. It has to be 3.3 V. Take it from the 5 V USB rail instead and the ADC clamps at full scale across the top third of the shaft travel, which feels exactly like an over-sensitive pot rather than a wiring fault, and on top of that, the RP2040's GPIO aren't 5 V tolerant, so you're damaging the part while you misdiagnose it.
The diagnosis is a multimeter and two minutes. Power off, probe the two outer legs: about 10 kΩ, and it must not change as you turn the shaft. Then wiper to one outer leg: that one must sweep smoothly from 0 to 10 kΩ. Power back on, meter from the wiper pin to ground: 0 to 3.3 V across full travel. If all three of those pass, the wiring is perfect.
Problem two: it's smoothed into a coma
Which brings me to the failure that looks the same and isn't. If the raw ADC value covers the full range but the dial still feels dead under your fingers, nothing is wrong with the wiring at all — the problem is the filter sitting behind it.
Raw analogue readings are noisy, and the RP2040's ADC is noticeably noisier than the AVR one a lot of hobby wiring assumes. Left unfiltered, the last couple of bits dither constantly and the LED shimmers at fixed knob positions. So you smooth it. Smooth it too hard, though, and you build in lag: an exponential average with a divisor of 16, polled every 20 ms, gives roughly a 320 ms time constant. A third of a second between moving the knob and seeing the light respond. Nobody reads that as "well filtered". They read it as broken.
There's a hardware half to this too; a 100 nF capacitor from the wiper to ground, which kills the noise at source and lets the software filter be much gentler. One component, a few pence, and it's not on the bench rig in the photo. That's going on next.
So today's job isn't glamorous. It's proving the divider is a divider, moving the reference to the right rail, adding the cap, and then retuning the filter until the knob is quiet at rest and immediate under the hand. There's a narrow band between jitter and mush, and finding it is entirely a matter of turning the thing and being honest about how it feels.
Why this is worth a day
The temptation is to shrug at it. The brightness works, it works from the simulator, which is the headline feature, and the pot is only a convenience on the bench.
Except it isn't, in the product. On a real panel that knob is the dimmer, and it's one of about four things a customer touches within thirty seconds of plugging the panel in. First impressions of hardware quality are made almost entirely by the things that move. A faceplate can be beautifully cut and perfectly backlit, and if the dimmer knob lags a third of a second behind your hand, the whole thing feels cheap.
Reference voltage and filter tuning is the least photogenic work on the whole project. It's also precisely the difference between a panel that works and a panel that feels right.
0 comments