For a while it just sat on the bench while I tried to decide what it should be<\/em>. The OLED and the LED board were still intact, which meant whatever I built could show both text and color. The obvious answer, the one I kept coming back to, was a build monitor. At work we’ve got a handful of Azure DevOps pipelines that I care about, and “is anything red right now?” is a question I answer by opening a browser tab and looking at a dashboard. A physical thing on a shelf that just tells<\/em> me seemed like a better answer.<\/p>\n\n\n\n A couple of decisions fell out of that pretty quickly:<\/p>\n\n\n\n That’s the first time it really looked like something. I had it cycling through some colors for testing ahead of wiring up the real application, but everything worked and looked pretty sweet (albeit crazy bright which I ended up dialing down in software later).<\/p>\n\n\n\n Here’s the whole thing on paper:<\/p>\n\n\n\n The OLED is straightforward SPI \u2014 clock, data, chip select, D\/C, reset, plus 3.3V and ground straight off the Pico. The NeoPixels are a single data line off GPIO15, daisy chained from the panel’s original board into the Jewel.<\/p>\n\n\n\n Power is where it gets slightly more interesting. Rather than run the Pico off USB and the LEDs off a separate supply, I run one 5V supply and “T” it: one leg to the LED chain, one leg to the Pico’s VSYS<\/strong> pin. That’s pin 39, and it’s the input the onboard regulator is designed to accept external power on. Not VBUS (pin 40) \u2014 that one’s tied to the USB rail, and I learned that feeding it can damage the Pi board. Splitting a single supply this way also hands you a shared ground for free, which the NeoPixels very much require. And because there’s a diode between VBUS and VSYS on the Pico, you can leave USB plugged in at the same time while you’re developing without the two supplies fighting which ended up being massively helpful while tweaking the software on this thing.<\/p>\n\n\n\n Here’s the one that I spent a lot of time on and almost gave up over. WS2812 pixels want a logic-high somewhere north of 0.7 \u00d7 VDD. The Pico’s GPIO is 3.3V. On a true 5V rail, that’s under<\/em> spec, and the symptom is maddening: the pixels get data \u2014 I could see it on my oscilloscope \u2014 but they mostly ignore it. Sometimes the first pixel lights, usually nothing, and sometimes it worked fine for a few minutes and then stopped.<\/p>\n\n\n\n The fix that finally worked was two silicon diodes in series in the LED’s +5V feed<\/strong> \u2014 not in the data line \u2014 dropping the pixel rail to roughly 4.2-4.4V and giving that 3.3V signal actual margin. I tried one diode first, and it almost<\/em> worked, which is the worst outcome. Forward voltage sags at low current, and this chain spends most of its life dim or idle, so a single ~0.6-0.7V drop kept wandering back out of spec. Two diodes, rock solid ever since. This is apparently common knowledge for smart people, and I saw a lot of posts online about it (after circling in on it by chatting with ChatGPT).<\/p>\n\n\n\n Worth checking your supply too, incidentally \u2014 some USB bricks like the one I’m using measure 5.4-5.5V under light load, which makes the margin problem worse than the initial math would suggest.<\/p>\n\n\n\n The pictures above and below show the wired-up mess at the back of the panel, and admittedly it’s messy. Every joint on that Pico is a small monument to enthusiasm exceeding technique \u2014 blobby, over-tinned, and held in position by optimism and hot glue. In my defense: the panel’s backing plate is the mounting surface, everything has to sit flat enough to still fit behind a curved bezel, and there was not a lot of room in there to be elegant.<\/p>\n\n\n\n It doesn’t look like much, but it hasn’t dropped a connection yet, so I’ve decided it’s a feature.<\/p>\n\n\n\n I did most of the ugly experimentation using a breadboard \u2014 which is where I dialed in that diode business \u2014 before committing anything to the panel itself. This picture above was the last part where I was figuring out the diode thing.<\/p>\n\n\n\n The panel is a curved face with nothing behind it, so it needed a body. I designed one in Tinkercad and printed it on my Prusa Core One, which I will take any excuse to mention because I love that printer. Big enclosed build volume, quiet, and it just prints \u2014 I’ve stopped thinking about first layers entirely, which is the highest compliment I can pay a 3D printer.<\/p>\n\n\n\n The design is deliberately dumb: an open-backed tray that the panel drops onto face-out, with all the electronics hanging down inside it. The panel is held on with velcro rather than screws, which means getting back to the Pico’s USB port is a matter of peeling the face off.<\/p>\n\n\n\n It took three revisions to get right, which I think is about par:<\/p>\n\n\n\n The STL is in the repo under This is the part I actually enjoyed, and the part where the design decisions mattered.<\/p>\n\n\n\n The single most important constraint came from the case: updating this thing is a pain.<\/strong> To reflash it I have to peel the panel off the case, find the USB cable, plug into the Pico, push files with In addition to the physical update process, the reality is that this is a simple IoT device that I might repurpose for anything, and instead of writing tedious code specific for one use case on the target, making it a wireless display and allowing external code to control it feels like the more natural fit. In my case I have a homelab Kubernetes cluster providing more than enough infrastructure to provide messaging and application hosting for the Azure build monitor today and whatever else I might want tomorrow.<\/p>\n\n\n\n So the firmware knows nothing<\/em> about builds, and it doesn’t know what Azure DevOps is. It stores no credentials beyond the WiFi password, makes no outbound calls to anything but the local MQTT broker, and listens on no inbound ports. It is a generic display device<\/strong>: it connects to WiFi, subscribes to one MQTT topic, and renders whatever JSON shows up there. All the interesting logic lives somewhere I can redeploy in thirty seconds.<\/p>\n\n\n\n That MQTT message contract is the whole design, and it looks roughly like this:<\/p>\n\n\n\n The goal was high-level but rich \u2014 one message should be able to express an entire visual state, and the device should own everything about how<\/em> that state gets rendered over time. Some of what it can do:<\/p>\n\n\n\n A few details are worth calling out that evolved organically while I was working on this project. First, the burn-in inversion is motion aware<\/em> \u2014 it only flips once the screen has held genuinely static content for a while, and any new content immediately un-inverts. Since the build monitor rotates through builds anyway, this just looked annoying and served no purpose. The one caveat is that if for some reason the application driving display messages stops updating the panel, the panel will protect itself automatically by using the invertion technique. Second call out is for the hidden LEDs: the panel’s board has 8 pixels but only 4 are visible, so the firmware keeps a map from logical position to physical position and never exposes the hidden ones over MQTT at all. Everything upstream sees a clean chain of 11 addressable pixels and has no idea there’s anything else on the wire. Had I thought about this before hot glueing everything together I would have popped the NeoPixel strip out and drilled 4 extra holes, but it’s simply not worth it to me anymore (but since it’s software configurable if I make another one down the road it’s a simple code change to re-enable it).<\/p>\n\n\n\n The device also publishes its last applied state back to a retained With the panel reduced to “renders JSON from a topic”, the rest is a plumbing problem:<\/p>\n\n\n\n The Go service is where all the real behavior lives, and it works on two timescales at once. It does a full refresh every hour<\/strong> \u2014 one API call that fetches the latest 4 builds for every pipeline and overwrites its in-memory view with the authoritative answer. That’s the drift-correction backstop. Then, for responsiveness, every webhook event patches<\/strong> that view in place immediately.<\/p>\n\n\n\n The webhook payload alone turned out not to be trustworthy enough to use directly, which was a fun little discovery: it carries no branch name, and its Every 5 seconds the service publishes a fresh command, and that’s what drives the little show:<\/p>\n\n\n\n Colors and blink timings are all configurable per status, and \u2014 this detail matters more than it sounds like it should \u2014 configurable separately<\/em> for the hexagon and the strip. The hexagon sits behind two layers of milk jug and the strip pixels don’t, so the same RGB triple reads as two completely different colors depending on which group it lands on.<\/p>\n\n\n\n The panel would connect to MQTT and then get its socket killed immediately, with the broker logging Worse \u2014 and later \u2014 well-formed clients started getting rejected with strange, inconsistent errors again. This time it genuinely wasn’t my code. My broker’s Kubernetes Service had This one landed a lot better than I expected. Most of my projects are fun first and useful second, if at all \u2014 this one is genuinely, boringly useful. It sits on a shelf above my little cluster of boards, and every morning I glance at it on my way past and know instantly whether anything needs my attention. No tab, no dashboard, no login.<\/p>\n\n\n\n The unexpected part is what that’s done to my behavior. When build health is a thing sitting in my peripheral vision, a red pixel is a small irritation that I want to make go away<\/em>, and I fix things the same day instead of discovering them on Thursday. I did not build this expecting to become a more disciplined engineer, and yet.<\/p>\n\n\n\n Next up, most likely: moving off my local broker onto a cloud-hosted message queue, so the panel doesn’t need to live on the same network as the service driving it. Then I can hang it on my cubicle wall at the office, which was sort of the point all along. Or I’ll just build a second one \u2014 assuming I can find another junk front panel, which is honestly the hard part.<\/p>\n\n\n\n Everything’s up on GitHub if you want a closer look \u2014 firmware, the Go service, the tester CLI, and the case STL:<\/p>\n\n\n\n\n
![\"Early](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-testing-front.jpg\")
Building the hardware<\/h2>\n\n\n\n
![\"Wiring](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-diagram-wiring-scaled.png\")
Parts in the panel<\/h3>\n\n\n\n
\n
The diode trick<\/h3>\n\n\n\n
About that soldering<\/h3>\n\n\n\n
![\"The](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-assembly-mess.jpg\")
![\"The](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-back-of-board.jpg\")
![\"Breadboard](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-testing-back.jpg\")
3D printing a chassis<\/h2>\n\n\n\n
![\"The](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-quad-t-front-panel-casing.png\")
![\"Three](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-case-revisions.jpg\")
\n
case-stl\/<\/code> if you happen to have a Quad-T front panel lying around, which, statistically, you do not.<\/p>\n\n\n\nBuilding the software<\/h2>\n\n\n\n
The firmware should be as dumb as possible<\/h3>\n\n\n\n
mpremote<\/code>, and put it all back together. That’s a five minute round trip for even a simple change.<\/p>\n\n\n\n{\n \"display\": {\n \"drawMode\": \"text2Line\",\n \"textLine1\": \"EchoCommon\",\n \"textLine2\": \"Success: 2 Days ago\",\n \"textLine1Align\": \"left\",\n \"textLine2AutoScroll\": true,\n \"oledBurnInProtectionMode\": \"invertDisplay\",\n \"oledBurnInProtectionInterval\": 60\n },\n \"leds\": [\n { \"r\": 0, \"g\": 255, \"b\": 0 },\n { \"r\": 255, \"g\": 0, \"b\": 0, \"displayMode\": \"blinkThruBlack\", \"blinkDuration\": 0.75 }\n ],\n \"transitionDuration\": 2.5,\n \"transitionType\": \"smooth\",\n \"pixelBrightness\": 1.0\n}<\/code><\/pre>\n\n\n\n\n
immediate<\/code>, smooth<\/code> (blend from current to target), or thruBlack<\/code> (fade down, then up into the new color), with a duration.<\/li>\n\n\n\nblink<\/code> for hard on\/off, or blinkThruBlack<\/code> for a gentle pulse, which is what “this pipeline is running right now” uses.<\/li>\n\n\n\nstate<\/code> topic, plus an online<\/code>\/offline<\/code> status<\/code> topic wired up as an MQTT Last Will \u2014 so anything that cares can tell at a glance whether the panel is actually alive.<\/p>\n\n\n\nGetting real build data to it<\/h3>\n\n\n\n
![\"How](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-diagram-data-flow-scaled.png\")
\n
run.statechanged<\/code> service hook whenever a build changes state.<\/li>\n\n\n\nazureBuildMonitor<\/code>, containerized and running in my k8s cluster) subscribes to that topic, keeps track of the world, and publishes display commands to the panel.<\/li>\n<\/ol>\n\n\n\npipelineId<\/code> field is actually the run<\/em> ID rather than the build definition ID that everything else is keyed on. So each event triggers exactly one “get build by ID” call to resolve the truth, and that result is what lands in the store. Events make it fast; the hourly sweep makes it correct.<\/p>\n\n\n\nWhat you actually see<\/h3>\n\n\n\n
\n
Two bugs that weren’t where I thought they were<\/h3>\n\n\n\n
Bad socket read\/write<\/code> and the client reporting a CONNACK “identifier rejected”. I spent an embarrassing amount of time on client IDs. The actual cause: umqtt’s default keepalive is 0<\/code>, and this particular mosquitto build accepts the CONNECT and then hangs up. Send a real keepalive and ping on it, and everything’s fine.<\/p>\n\n\n\nexternalTrafficPolicy: Cluster<\/code>, which let MetalLB’s L2 speaker answer ARP from a node that wasn’t the one running the mosquitto pod, forcing an extra kube-proxy SNAT hop that corrupted connections from at least one client. One word changed to Local<\/code> and it’s been quiet ever since. I’d already rewritten a working MQTT library twice by then, chasing a bug that lived three layers below it.<\/p>\n\n\n\n![\"MQTT](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-testing-oled.jpg\")
So where are we, and what’s next?<\/h2>\n\n\n\n
![\"The](\"https:\/\/www.knightware.net\/wp-content\/uploads\/2026\/08\/quad-t-assembled-unit-running-2-scaled.jpg\")