Archive for category Software
Vacuum Tube LEDs: Arduino Pro Mini vs. NP-BX1 Battery
Posted by Ed in Electronics Workbench, Software on 2019-01-28
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:
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:
It was just sitting there, so why not?
Seen with a bit more detail on a better scope:
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:
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:
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:
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
Posted by Ed in Electronics Workbench, Software on 2019-01-17
The LED parts box disgorged some single-color Pirhana-style LEDs:
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:
The circuitry is the same as the First Light version, with a 1 MΩ resistor stabilizing the LED ballast resistor:
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
Posted by Ed in Machine Shop, Software on 2019-01-14
[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
Alas, the recessed letters become lost in their perimeter threads:
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
Which looks OK in the real world, too:
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
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
Posted by Ed in Electronics Workbench, Software on 2019-01-09
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 192.168.1.41 -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:
The BMP header contains the correct size at offset +0x02:
lxi screenshot -a 192.168.1.41 -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:
#!/bin/bash lxi screenshot -a 192.168.1.41 -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/getsdm3045x.sh testfix Saved screenshot image to /tmp/testfix.bmp Screenshot: testfix.png
Sheesh & similar remarks.
Astable Multivibrator: RGB LED and Radome Spider
Posted by Ed in Electronics Workbench, Machine Shop, Software on 2018-12-28
Well, a spider with half the proper leg count:
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
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
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
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
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
Posted by Ed in Electronics Workbench, Software on 2018-12-21
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_CONTACTS = 2;
T_KEYS = 3;
BatteryData = [
["NP-BX1",[43.0,30.0,9.5],[[-0.75,6.0,6.2],[-0.75,16.0,6.2]],[[1.70,3.70,2.90],[1.70,3.60,2.90]]],
["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]]],
["NB-6L",[42.5,35.5,7.0],[[-0.85,5.50,3.05],[-0.85,11.90,3.05]],[[2.0,0.70,2.8],[2.0,2.00,2.8]]],
];
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:
Which looks about like you’d expect in real life:
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:
-
You are currently browsing the archives for the Software category.
Blowback