Archive for category Software

Vacuum Tube LEDs: Arduino Pro Mini vs. NP-BX1 Battery

A year or so ago, a certain Young Engineer suggested my Vacuum Tube Lights really needed battery power and rebuffed my feeble objections concerning low LED intensity (3.6-ish V, not plug-in 5 V USB) and short run time (because three constantly lit LEDs draw too much current). Having a spare NP-BX1 holder lying about, here’s a feasibility study:

Arduino Pro Mini - Neopixel - NP-BX1 battery
Arduino Pro Mini – Neopixel – NP-BX1 battery

Not much to it, eh?

Hitching the DSO150 to a Tek current probe (which needs a 50 Ω load, thus the terminator on the BNC tee) seems a clear-cut case of a sow’s ear joining forces with a silk purse:

DSO150 - Arduino Pro Mini - Neopixel current
DSO150 – Arduino Pro Mini – Neopixel current

It was just sitting there, so why not?

Seen with a bit more detail on a better scope:

Ard Mini - NP-BX1 - SK6812 - 10 mA-div
Ard Mini – NP-BX1 – SK6812 – 10 mA-div

Each vertical increment represents the current into a single LED (at 10 mA/div), with the PWM cycles ticking along at 1.3 kHz.

The current steps aren’t the same height, because the LEDs have different forward voltages. The taller step (at the top) probably comes from the red LED, with the other two being blue and green. The maximum current is only 40 mA, not the 60 mA you’d expect with a 5 V supply.

The PWM width, of course, determines the brightness of each LED. Eyeballometrically, the average current will be half of 40 mA for (just less than) half of each PWM cycle, so figuring each SK6812 module (there’s only one here) will draw 10 mA seems reasonable.

The “base load” from the Arduino looks like 2 mA, so there’s not much point in removing its power and status LEDs.

The NP-BX1 lithium cell has lost enough capacity to no longer power my Sony HDR-AS30V helmet camera for at least half of a typical ride. The camera draws around 1 A, so you can clearly see the defunct batteries:

Sony NP-BX1 - 2018-04-24
Sony NP-BX1 – 2018-04-24

If the average voltage during discharge is 3.3. V, then a 10 mA load would be 33 mW and a defunct NP-BX1 battery with 2 W·h capacity (at 1 A) might provide 60 hours of continuous use. I’d expect more capacity at lower current, although it’s not clear the cells actually behave that way.

So a battery-powered Vacuum Tube Light might make sense, perhaps as romantic illumination for techie snuggling:

21HB5A - Guilloche platter
21HB5A – Guilloche platter

Ya never know …



Encrypted Email: What Could Possibly Go Wrong?

So this arrived from an email address similar to, yet not quite the same as, the URL of a physician’s office where I had an appointment a few days hence:

Encrypted Email Message
Encrypted Email Message

My email client is set to prefer plain text, disallow remote content, and not open attachments, so that’s as far as it got. Donning asbestos work gloves and face mask, I pried open the message and its attached HTML file with the appropriate tools and found, as expected, scripts doing who-know-what.

Called the office and, also as expected, was told my appointment time had been changed.

Showed up, mentioned it to the doctor, and was told the office must check off many boxes to demonstrate its HIPAA compliance.

Bottom line: HIPAA now requires patients (a.k.a., us) to open random attachments from random senders, all in the name of privacy.

Banks do that, too.


Astable Multivibrator: Monochrome Pirhana LED

The LED parts box disgorged some single-color Pirhana-style LEDs:

Astable - 2N7000 - Mono Pirhana LED
Astable – 2N7000 – Mono Pirhana LED

Didn’t quite catch the blink, but the Ping-Pong ball radome lights up just as you’d expect.

The radome sits on a stripped-down RGB LED spider:

Astable Multivibrator Battery Holder - mono LED Spider - fit view
Astable Multivibrator Battery Holder – mono LED Spider – fit view

The circuitry is the same as the First Light version, with a 1 MΩ resistor stabilizing the LED ballast resistor:

Astable - 2N7000 - Mono Pirhana LED - detail
Astable – 2N7000 – Mono Pirhana LED – detail

Those are 1 µF ceramic caps in the astable section, so I’m no longer abusing electrolytics, and a stylin’ 100 nF film cap metering out the LED pulse up above.

Just for pretty, I’ve been using yellow / black wires for the battery connections and matching the LED color with its cathode lead.

The OpenSCAD source code as a GitHub Gist:



Debossed Printed Legends

[Update: It seems I interchanged “em” and “de” throughout this post.  ]

Up to this point, I’ve been labeling printed parts with emdebossed legends that look OK on the solid model:

Astable Multivibrator Battery Holder

Astable Multivibrator Battery Holder

Alas, the recessed letters become lost in their perimeter threads:

3D Printed Legend - Embossed

3D Printed Legend – Embossed

Raising the legend above the surface (“deembossing”) works reasonably well, but raised letters would interfere with sliding the battery into the holder and tend to get lost amid the surface infill pattern.

The blindingly obvious solution, after far too long, raises the letters above a frame embossed into the surface:

Astable Multivibrator Battery Holder - Legend Debossed

Astable Multivibrator Battery Holder – Legend Debossed

Which looks OK in the real world, too:

3D Printed Legend - Debossed

3D Printed Legend – Debossed

The frame is one thread deep and the legend is one thread tall, putting the letters flush with the surrounding surface and allowing the battery to slide smoothly.

The legend on the bottom surface shows even more improvement:

NP-BX1 battery holder - Raised vs Recessed Legend

NP-BX1 battery holder – Raised vs Recessed Legend

An OpenSCAD program can’t get the size of a rendered text string, so the fixed-size frame must surround the largest possible text, which isn’t much of a problem for my simple needs.

, ,


Siglent SDM3045X Screen Shot File

As with the Siglent SDS2304X oscilloscope, the SDM3045M multimeter delivers broken screen shot files over the network: the actual file size doesn’t match the BMP file size field, causing kvetching in subsequent use:

[ed@shiitake tmp]$ lxi screenshot -a -p siglent-sdm3000 test.bmp
Saved screenshot image to test.bmp
[ed@shiitake tmp]$ convert test.bmp test.png
convert-im6.q16: length and filesize do not match `test.bmp' @ warning/bmp.c/ReadBMPImage/831.

Files stored on a USB stick jammed into the meter’s front panel have the correct size, so it’s not clear where the fault lies.

Because the files contain extra data following the (intact) image, it will display correctly:

Astable - 2N7000 - IDSS cal
Astable – 2N7000 – IDSS cal

The BMP header contains the correct size at offset +0x02:

lxi screenshot -a -p siglent-sdm3000 test.bmp
hexdump -C test.bmp | head
00000000  42 4d 36 fa 05 00 00 00  00 00 36 00 00 00 28 00  |BM6.......6...(.|
00000010  00 00 e0 01 00 00 10 01  00 00 01 00 18 00 00 00  |................|
00000020  00 00 00 fa 05 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The horizontal image size at +0x12 and vertical size at +0x6 are correct: the screen is 480×272 pixels. Each pixel has three bytes = 24 bits, as specified at +0x1C.

So the file should contain 0x0005fa36 = 391734 bytes, but, as delivered, it’s much, much larger:

ll --block-size=1 test.bmp
-rw-rw-r-- 1 ed ed 1152054 Dec 26 08:45 test.bmp

Oddly, 1552054 bytes is exactly the size the oscilloscope files should be. I have no explanation, although it looks like a copypasta error.

As before, the simplest solution is to truncate the file and be done with it:

lxi screenshot -a -p siglent-sdm3000 /tmp/"$1".bmp
truncate --size=391734 /tmp/"$1".bmp
convert /tmp/"$1".bmp "$1".png
echo Screenshot: "$1".png

And then It Just Works:

~/bin/ testfix
Saved screenshot image to /tmp/testfix.bmp
Screenshot: testfix.png

Sheesh & similar remarks.

1 Comment

Astable Multivibrator: RGB LED and Radome Spider

Well, a spider with half the proper leg count:

RGB LED - radome test

RGB LED – radome test

One could argue the LED spider has an unusually large abdomen, but I’m not going there.

The solid model looks the same way:

Astable Multivibrator Battery Holder - RGB LED Spider - radome

Astable Multivibrator Battery Holder – RGB LED Spider – radome

And, yes, those are eye protection caps over the four wire struts, most useful during construction while maneuvering the radome into position.

For reasons unknown to me, they’re called “Pirhana” LEDs:

RGB LED - wiring

RGB LED – wiring

I trimmed off half of each pin, soldered on 28 AWG color-coded silicone wires, threaded wires through openings, then rammed the LED package into the recess so it sits just below the radome’s curve. The dent matching the ball comes from the chord equation, as always, and looks pretty good.

The radome is, of course, a one-star ping pong ball from the usual big box retailer’s sporting goods section. The stamped logo sits at a random position with respect to the ball’s interior structure (visible when lit, as in the top picture), so I erased it with a fine-grit sanding sponge. Hollow plastic golf balls might work just as well, with an even more interesting surface texture.

The source code includes a cutaway look at the printed parts to verify their innards:

Astable Multivibrator Battery Holder - RGB LED Spider - fit view

Astable Multivibrator Battery Holder – RGB LED Spider – fit view

The OpenSCAD source code as a GitHub Gist:

The original doodles give useful dimensions, plus some details not withstanding the test of time:

RGB LED Radome Spider - doodles

RGB LED Radome Spider – doodles

The actual center-to-center distances for the wire posts come from the battery dimensions, rounded up or down as appropriate, to the nearest multiple of 5 mm, so those are just serving suggestions.



Astable Multivibrator: Battery Base for RGB LED

Collecting the battery dimensions into a table should make it easier to generate new holders for astable multivibrators:

//- Battery dimensions - rationalized from several samples
//  Coordinate origin at battery end with contacts, key openings downward

T_NAME = 0;
T_SIZE = 1;
T_KEYS = 3;

BatteryData = [
  ["NB-5L", [45.0,32.0,8.0],[[-0.82,4.5,3.5],[-0.82,11.0,3.5]],[[2.2,0.75,2.0],[2.2,2.8,2.0]]],

echo(str("Battery: ",BatteryName));

BatteryIndex = search([BatteryName],BatteryData,1,0)[0];
echo(str(" Index: ",BatteryIndex));

BatterySize = BatteryData[BatteryIndex][T_SIZE];          // X = length, Y = width, Z = thickness
echo(str(" Size: ",BatterySize));

Contacts = BatteryData[BatteryIndex][T_CONTACTS];         // relative to battery edge, front, and bottom
echo(str(" Contacts: ",Contacts));

ContactOC = Contacts[1].y - Contacts[0].y;                // + and - terminals for pogo pin contacts
ContactCenter = Contacts[0].y + ContactOC/2;

KeyBlocks = BatteryData[BatteryIndex][T_KEYS];            // recesses in battery face set X position
echo(str(" Keys: ",KeyBlocks));

A new boolean, RGBCircuit, adds a second pair of wire strut bases and punches holes in them:

Astable Multivibrator Battery Holder
Astable Multivibrator Battery Holder

Which looks about like you’d expect in real life:

 Astable - NP-BX1 RGB holder
Astable – NP-BX1 RGB holder

The lettering, of course, doesn’t come through clearly, but it suffices as a hint for which battery to use.

The four vertical struts will support three astable multivibrators, each driving one color of a common-anode RGB LED. It remains to be seen if there’s enough room for all the parts along the sides of the battery pack.

The OpenSCAD source code as a GitHub Gist:

1 Comment