Posts Tagged Arduino
You’ll recall the LED atop the 21HB5A tube failed, shortly after replacing the bottom LED and rewiring the ersatz plate lead, which led me to rebuild the whole thing with SK6812 RGBW LEDs. So I printed all the plastic parts again, because the duodecar tube socket’s pin circle can fit into a hard drive platter’s unmodified 25 mm hole, then drilled another platter to suit:
The hole under the drill fits the 3.5 mm stereo socket for the ersatz plate lead, so it’s bigger than before.
I’ve switched from Arduino Pro Minis with a separate USB converter to Arduino Nanos with an on-board CH340 USB chip, because the fake FTDI chips on the converters are a continuing aggravation:
Adding those wire slots to the sockets definitely helps tidy things up; the wires no longer need a crude cable tie anchoring them to the socket mounting screws.
I wanted to drive the LEDs from the A7 pin, rather than the A3 pin I’d been using on the Pro Minis, to keep the wires closer together, but it turns out that A6 and A7 can’t become digital output pins. So I used A5, although I may come to regret the backward incompatibility.
In any event, the 21HB5A tube looks spiffy with its new LEDs in full effect:
I dialed the white LED PWM down to 32, making the colors somewhat pastel, rather than washed-out.
The Arduino source code as a GitHub Gist:
The failed WS2812 pixel remains defunct:
Attach scope probes to its data input and output pins (with the fixture face-down on the bench):
The output no longer comes from the Land of Digital Signals:
I immediately thought the broken bits occupied the first 24 bit times, when the WS2812 controller should be absorbing those bits from the incoming stream. The vertical cursors show the failed bits occupy 54 µs = 40-ish bit times at 800 kHz (or you can count them), so it’s worse than a simple logic failure.
A closer look:
At least for those bits, neither output transistor works well at all. On the other paw, the output shouldn’t even be enabled for the first 24 bits, so there’s that to consider.
Lo and behold, it also fails the Josh Sharpie Test:
You may recall it passed the leak test shortly before I assembled the test array a month ago. Evidently, just few days of operation suffices to wreck the seal, let air / moisture into the package, and kill the controller. Not a problem you’d find during a production-line test (assuming there is such a thing), but it should certain appear during the initial design & production qualification test phase (another assumption).
Weirdly, a day after taking that photo, the controller began working perfectly again and the LEDs look just like they should: there is no explaining that!
SK2812 in the title and elsewhere should be
SK6812. If I change the title, then all the other links break. So it goes.]
An envelope of RGBW LEDs, allegedly with SK6812 controllers, arrived from halfway around the planet:
The yellow phosphor sauce poured atop the blue LED on the left that makes it glow white leaves the upper loop of two wire bonds sticking out, but I can’t fault ’em for that. The overall build quality looks better than the ill-fated WS2812 LEDs, although it’s hard to tell by looking.
I conjured a test stand from the vasty digital deep by tweaking the WS2812 mount:
Wiring up a 5×5 panel went as before:
The array test code adds another pixel channel and runs another raised sine wave with another random period, accomplished without much hackage.
With the warm-white LED at full throttle (
MaxPWM = 255), the panel tends toward the pallid end of HSV space:
Dialing the white
MaxPWM back to 32 crisps things a bit:
Of course, the RGBW data stream isn’t compatible with the RGB data stream, so vacuum tubes with SK6812 chips require a slightly different driver and I can’t mix the two chips on a single tube.
The Arduino source code as a GitHub Gist:
A few days after epoxying a replacement WS2812 RGB LED into the base of the 21HB5A and, en passant, soldering a 3.5 mm plug-and-jack into the plate lead for EZ removal, the top LED failed.
In this case, it also failed the Josh Sharpie test with bad encapsulation sealing:
Here’s a view from another angle, with a warm-white desk lamp for a bit of color:
Those patterns took a few days to appear and also showed up in some, but not all, of the previous failing LEDs.
Although I have no idea what’s going on, it’s certainly distinctive!
An envelope of RGBW LEDs, allegedly with SK2812 controllers, has arrived from a different eBay supplier, so it’s time for an upgrade.
Well, that didn’t take long:
The red spot in the next-to-bottom row of the test fixture (*) marks a failed WS2812 LED. All of the LEDs above it, plus the LED just to its left, are in pinball panic mode: random colors flicker across the panel as the LED’s controller transmits garbled data and the downstream LEDs pass it on.
This failure provides several bits of information:
- The LED sees the same power supply as all the rest, so it’s not a power thing
- The LED gets data from the adjacent WS2812, so it’s not an Arduino output thing
- It failed after about four days = 100 hours of continuous operation
I connected the previous LED’s output (#6) to the next one’s input (#8), so the failed LED (#7, now with output disconnected) continues to flicker, but doesn’t influence any of the downstream LEDs.
(*) The LEDs are daisy-chained from lower right to upper left, row by row, so that’s LED #7 of 28.
At 200 mA/div, the top trace shows a bit under 1.2 A, a bit under the 1.68 A = 28 × 60 mA you’d expect; in round numbers, each RGB pixel draws 43 mA. Actually, the WS2812 specs don’t specify the maximum / typical LED current and, on belief and evidence, I doubt these units meet any particular specs you’d care to cite.
Also, the supply voltage (measured across the LED array “bus bar” wires) hits 3.37 V, well under the 5 V you’d expect from a USB charger and less than the 3.5 V called for by the WS2812 specs. Although the WS2812 nominally limits the LED current, there’s no telling how it varies with supply voltage.
A cheap USB 1 A wall-wart charger produced far more hash:
That’s with an additional 20 µF of tantalum capacitance across the power bus bars. The peak current looks like 1.4 A, with marginally more supply voltage at 3.56 V.
Bumping the trace speed shows the wall wart produces nasty current spikes, at what must be the poor thing’s switching speed, as it desperately tries to produce enough juice for the LEDs:
The step over on the right looks like a single RGB LED going dark, as it’s about 50 mA tall.
The output voltage doesn’t show the same spikes, so the LED array acts like a constant-voltage load. Given that the WS2812 probably connects all the LEDs pretty much straight across the supply, that’s not far from the truth: we’re looking at the forward drop of those blue LEDs.
Now, to let it cook away in the cool and the dark of the Basement Laboratory…
Mounting the ungainly WS2812 LED test fixture seemed like a Good Idea to keep the electricity out of the usual conductive litter:
The solid model shows more details:
The power wires along the array edges slide into the rear (thinner) slot, with enough friction from a few gentle bends to hold the whole mess in place.
The knockoff Arduino Nano rests on the recessed ledge in the pit, with M2 screws and washers at the corners holding it down (the PCB’s built-in holes might work with 1 mm or 0-90 screws, but that’s just crazy talk). I soldered the power wires directly to the coaxial jack pins under the PCB; they snake out to the LEDs through the little trench. There should be another cutout around the USB connector for in-situ programming, although the existing code works fine.
The front (wider) slot holds a piece of translucent white acrylic to diffuse the light:
It’s painfully bright: a few layers of neutral density filter would be appropriate for a desk toy.
The array runs hot enough at MaxPWM = 255 to produce a gentle upward breeze.
It looks even better without the flash:
You’ll find many easier ways to get RGB LED panels, but that’s not the point here; I’m waiting for these things to die an unnatural death.
The OpenSCAD source code as a GitHub Gist: