The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Electronics Workbench

Electrical & Electronic gadgets

  • Monthly Science: Final WS2812 Failures

    My “exhibit” at the MHV LUG Mad Science Fair consisted of glowy and blinky LED goodness, with an array of vacuum tubes, bulbs, and the WS2812 and SK6812 test fixtures:

    MHVLUG Science Fair - Chastain - highres_463020980
    MHVLUG Science Fair – Chastain – highres_463020980

    They look much better without a flash, honest. The cut-up cardboard box threw much needed shade; the auditorium has big incandescent can lights directly overhead.

    Anyhow, what with one thing and another, the two LED test fixtures spent another few dark and cool days in the Basement Laboratory. When I finally plugged them in, the SK6812 RGBW LED array light up just fine, but three more WS2812 RGB LEDs went toes-up:

    WS2812 LED test fixture - more failures
    WS2812 LED test fixture – more failures

    That brought the total to about 8 (one looks like it’s working)  out of 28: call it a 28% failure rate. While WS2812 LEDs don’t offer much in the way of reliability, running them continuously seems to minimize the carnage.

    So I wired around the new deaders and took that picture.

    Flushed with success and anxious to get this over with, I sealed the tester in a plastic bag and tossed it in the freezer for a few hours …

    Which promptly killed most of the remaining WS2812 chips, to the extent even a protracted session on the Squidwrench Operating Table couldn’t fix it. When I though I had all the deaders bypassed, an LED early in the string would wig out and flip the panel back to pinball panic mode.

    It’s not a 100% failure rate, but close enough: they’re dead to me.

    As the remaining WS2812 LEDs on the various vacuum tubes and bulbs go bad, I’m replacing them with SK6812 RGBW LEDs.

    For whatever it’s worth, freezing the SK6812 tester had no effect: all 25 LEDs lit up perfectly and run fine. Maybe some of those chips will die in a few days, but, to date, they’ve been utterly reliable.

  • Calculator Battery Corrosion

    The display on Mary’s favorite little calculator (remember calculators?) faded away and, of course, this appeared when I popped the back:

    Calculator battery corrosion
    Calculator battery corrosion

    A touch of vinegar, some scrubbing, and new cells restored it to good health.

    That was easy …

  • Vacuum Tube LEDs: Knockoff Arduino Nano USB Connector

    The LEDs adorning the 0D3 rectifier tube became unreliable:

    0D3 Octal - 25 mm socket - raised LED
    0D3 Octal – 25 mm socket – raised LED

    After failing to plug in a different USB power supply, a close look at the USB connector showed the problem:

    Knockoff Arduino Nano - broken Mini-B connector
    Knockoff Arduino Nano – broken Mini-B connector

    A bit of needle-nose tweezering extracted the culprit from the power supply’s connector:

    Knockoff Arduino Nano - broken Mini-B connector - fragment
    Knockoff Arduino Nano – broken Mini-B connector – fragment

    I tried applying the world’s smallest dot of epoxy to the fracture, probably slobbered epoxy along the pins while reinserting it, and the Nano still doesn’t light up.

    Given that knockoff Nano boards cost a touch over two bucks delivered, it’s not clear transplanting a connector from one of the never-sufficiently-to-be-damned counterfeit FTDI USB adapters makes any sense.

  • Vacuum Tube LEDs: Mogul Bulb Side Light

    The knockoff Neopixel on the 500 W mogul-base bulb failed in the usual way, so I rebuilt it with an SK6812 RGBW LED in a round cap:

    Mogul lamp socket - SK6812 LED side cap
    Mogul lamp socket – SK6812 LED side cap

    The nice 1-¼ inch stainless socket-head cap screws replace the 1 inch pan-head screws that engaged maybe one thread due to the additional spacer between the USB port and the upper hard drive platter I added for good looks.

    I tried a few iterations of an aluminized Mylar (*) disk with various sized pinholes over the RGB trio to crisp up the filament shadow, because the SK6812 LED casts a more diffuse light than the W2812 LEDs:

    Aluminized Mylar pinholes for SK6812 RGBW LED
    Aluminized Mylar pinholes for SK6812 RGBW LED

    Even the ⅛ inch pinhole made the bulb too dim, so I settled for a fuzzy shadow:

    500 W Mogul bulb - SK6812 RGBW LED - no pinhole - green phase
    500 W Mogul bulb – SK6812 RGBW LED – no pinhole – green phase

    The firmware has a tweak forcing the white LED to PWM=0, because this bulb looks better in saturated colors.

    (*) Here on earth, aluminized Mylar is nonconductive.

  • Byonics TinyTrak3+ vs. RFI

    Some weeks ago, the APRS + voice adapter on my radio began randomly resetting during our rides, sending out three successive data bursts: the TinyTrak power-on message, an ID string, and the current coordinates. Mary could hear all three packets quite clearly, which was not to be tolerated.

    I swapped radios + adapters so that she could ride in peace while I diagnosed the problem, which, of course, was both intermittent and generally occurred only while on the road. The TinyTrak doc mentions “… a sign of the TinyTrak3 resetting due to too much local RF energy”, so I clamped ferrite cores around All! The! Cables! and the problem Went Away.

    Removing one core each week eventually left the last core on the GPS receiver’s serial cable, which makes sense, as it plugs directly into the TT3. The core had an ID large enough for several turns (no fool, I), another week established a minimum of three turns kept the RFI down, so I settled for five:

    KG-UV3D APRS - ferrite on TT3 GPS cable
    KG-UV3D APRS – ferrite on TT3 GPS cable

    Prior to the RFI problem cropping up, nothing changed. Past experience has shown when I make such an assertion, it means I don’t yet know what changed. Something certainly has and not for the better.

    I swapped the radios + adapters and all seems quiet.

  • Cylindrical Cell Adapter: 18650 to 3xAAA

    Anker LC40 flashlights can use either one lithium 18650 cell or an adapter holding three AAA cells. I now prefer 18650 cells, but they’re nigh onto 4 mm smaller than the flashlight ID and rattle around something awful.

    I can fix that:

    Anker LC40 with 18650 cell adapter
    Anker LC40 with 18650 cell adapter

    Three new entries appear in the cell dimension table of my OpenSCAD inter-series battery adapter program:

    NAME = 0;
    ID = 0;       // for non-cell cylinders
    OD = 1;
    LENGTH = 2;
    
    Cells = [
      ["AAAA",8.3,42.5],
      ["AAA",10.5,44.5],
      ["AA",14.5,50.5],
      ["C",26.2,50],
      ["D",34.2,61.5],
      ["A23",10.3,28.5],
      ["CR123A",17.0,34.5],
      ["18650",18.8,65.2],
      ["3xAAA",21.2,56.0],
      ["AnkerLC40",23.0,55.0]           // Flashlight tube loose-fit for 3xAAA adapter
    ];
    

    I took the opportunity of adding OpenSCAD Customizer comments, which means this now works:

    OpenSCAD Customizer - dropdown selections
    OpenSCAD Customizer – dropdown selections

    The model looks about the same as before, although with a few more sides just for pretty:

    AnkerLC40 vs. 18650 Sleeve - Slic3r
    AnkerLC40 vs. 18650 Sleeve – Slic3r

    That was easy …

  • LF Crystal Tester: OLED Noise vs. Log Amp

    Having installed a cheap USB isolator to remove some obvious 60 Hz interference, the 100 Hz OLED refresh noise definitely stands out:

    Log amp - xtal amp - OLED noise
    Log amp – xtal amp – OLED noise

    The bottom trace comes from the 100× = 40 dB MAX4255 amplifier boosting the crystal output to a useful level. The fuzz on the waveform is actually the desired (off resonance) 60 kHz signal at maybe 30 mVpp, so the input is 300 µVpp.

    The worst part of the OLED noise looks like 100 mVpp, for about 1 mVpp at the crystal output, call it +10 dB over the desired signal. Some high-pass filtering would help, but it’s easier to just shut the display off while measuring the crystal.

    The top trace is the log amp output at (allegedly) 24 mV/dBV. The input bandwidth obviously extends way too low, as it’s neatly demodulating the input signal: the peaks correspond to both the positive and negative signal levels, so reducing the 1 µF input coupling caps will be in order.

    In between those 100 Hz groups, the input signal shines through to the log amp output at the V1 cursor. The peak noise rises 290 mV above that, so the log amp thinks it’s 12 dB higher. Pretty close to my guesstimated 10 dB, methinks.

    So, turning off the OLED should help a lot, which is feasible in this situation. If you must run the display while caring deeply about signal quality, you must devote considerably more attention to circuit construction quality.