Posts Tagged Arduino

Crystal Parameter Measurement Musings

In order to probe a crystal’s response with decent resolution, I need a gadget to step a decent-quality sine wave by 0.01 Hz across the 10-to-100 kHz range and a logarithmic front end with a decent dynamic range. That’s prompted by looking at crystal responses through the SA’s 30 Hz resolution bandwidth:

Quartz Resonator 32.765 kHz - 34.6 pF

Quartz Resonator 32.765 kHz – 34.6 pF

Mashing a cheap AD9850/AD9851 DDS board against an Arduino Pro Mini, adding a knob, and topping with a small display might be useful. A Raspberry Pi could dump the response data directly into a file via WiFi, which may be more complication that seems warranted.

The DDS boards come with absurdly high-speed clock generators of dubious stability; a slower clock might be better. A local 10 MHz oscillator, calibrated against the 10 MHz output of the HP 3801 GPS stabilized receiver would be useful. If the local oscillator is stable enough, a calibration adjustment might suffice: dial for 10 MHz out, then zero-beat with the GPS reference, so that the indicated frequency would be dead on to a fraction of 1 Hz.

The HP 8591 spectrum analyzer has a better-quality RF front end than I can possibly build (or imagine!), but, at these low frequencies, a simple RF peak detector and log amp based on the ADL5303 or ADL5306 should get close enough. One can get AD8302 / AD8310 chips on boards from the usual low-budget suppliers; a fully connectorized AD8310 board may be a good starting point, as it’s not much more than the single-connector version.

With frequencies from 10 kHz to 100 kHz coming from a local oscillator, one might argue for a synchronous detector, formerly known as a lock-in amplifier. A Tayloe Detector might be a quick-and-dirty way to sweep a tracking-filter-and-detector over the frequency range. Because it’s a tracking generator, the filter bandwidth need not be very tight.

At some point, of course, you just digitize the incoming signal and apply DSP, but the whole point of this is to poke around in the analog domain. This must not turn into an elaborate software project, too.



, ,


Vacuum Tube Lights: Duodecar Rebuild

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:

Duodecar disk drilling

Duodecar disk drilling

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:

21HB5A base - interior

21HB5A base – interior

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:

21HB5A with RBGBW LEDs - cyan violet phase

21HB5A with RBGBW LEDs – cyan violet phase

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:

, , ,

1 Comment

Cheap WS2812 LEDs: Failure Waveforms

The failed WS2812 pixel remains defunct:

WS2812 array - failure 1

WS2812 array – failure 1

Attach scope probes to its data input and output pins (with the fixture face-down on the bench):

WS2812 LED - fixture probing

WS2812 LED – fixture probing

The output no longer comes from the Land of Digital Signals:

WS2812 Array Fail 1 - in vs out

WS2812 Array Fail 1 – in vs out

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:

WS2812 Array Fail 1 - in vs out - detail

WS2812 Array Fail 1 – in vs out – detail

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:

WS2812 LED - test array failure 1 - ink test

WS2812 LED – test array failure 1 – ink 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 RGBW LED: Test Fixture

[Edit: The 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:

SK2812RGBW LEDs - as received

SK2812RGBW LEDs – as received

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:

SK6812 LED Array Test Fixture - Slic3r preview

SK6812 LED Array Test Fixture – Slic3r preview

Wiring up a 5×5 panel went as before:

SK2812RGBW test fixture - rear

SK2812RGBW test fixture – rear

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:

SK2812RGBW test fixture - front - W PWM255

SK2812RGBW test fixture – front – W PWM255

Dialing the white MaxPWM back to 32 crisps things a bit:

SK2812RGBW test fixture - front - W PWM32

SK2812RGBW test fixture – front – W PWM32

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:

, ,


Cheap WS2812 LEDs: Another Failure

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.

21HB5A - Audio plug cable

21HB5A – Audio plug cable

In this case, it also failed the Josh Sharpie test with bad encapsulation sealing:

WS2812 LED failure - ink test patterns

WS2812 LED failure – ink test patterns

Here’s a view from another angle, with a warm-white desk lamp for a bit of color:

WS2812 LED failure - ink test patterns - 2

WS2812 LED failure – ink test patterns – 2

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.



Cheap WS2812 LEDs: Test Fixture Failure 1

Well, that didn’t take long:

WS2812 array - failure 1

WS2812 array – failure 1

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.


Cheap WS2812 LEDs: Test Fixture Current

With the WS2812 test fixture neatly mounted, I plugged it into a six-port USB charger allegedly capable of supplying 2.4 A per port and captured a trace with nearly all 28 LEDs displaying full white:

WS2812 4x7 array - 200 mA VCC - all on

WS2812 4×7 array – 200 mA VCC – all on

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:

WS2812 4x7 array - 200 mA VCC - all on - cheap 1A wart - 20 uF

WS2812 4×7 array – 200 mA VCC – all on – cheap 1A wart – 20 uF

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:

WS2812 4x7 array - 200 mA VCC 50 us - all on - cheap 1A wart - 20 uF

WS2812 4×7 array – 200 mA VCC 50 us – all on – cheap 1A wart – 20 uF

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…