Archive for category Software
I’ve been using YAGV (Yet Another G-Code Viewer) as a quick command-line Guilloché visualizer, even though it’s really intended for 3D printing previews:
Oddly (for a command-line program), it (seems to) lack any obvious keyboard shortcut to bail out; none of my usual finger macros work.
A quick hack to the main
/usr/share/yagv/yagv file makes Ctrl-Q bail out, thusly:
diff yagv /usr/share/yagv/yagv 18a19 > import sys 364a366,367 > if symbol==pyglet.window.key.Q and modifiers & pyglet.window.key.MOD_CTRL: > sys.exit()
I tacked the code onto an existing issue, but yagv may be a defunct project. Tweaking the source works for me.
The Ubuntu 18.04 LTS repo has what claims to be version 0.4, but the yagv GitHub repository (also claiming to be 0.4) includes code ignoring G-Code comments. Best to build the files from source (which, being Python, they already are), then add my Ctrl-Q hack, because my GCMC Guilloché generator adds plenty of comments.
Because the COB LEDs dissipate 6W, far more power than I’m comfortable dumping into a 3D printed structure, I redefined a length of aluminum shelf bracket extrusion to be a heatsink and epoxied the module’s aluminum back plate thereto:
Unlike the flexible LED strips, the COB LED modules have no internal ballast resistors and expect to run from a constant-current supply. Some preliminary testing showed we’d want less than the maximum possible light output, so a constant-voltage supply and a few ohms of ballast would suffice:
With all that in hand, the heatsink extrusion cried out for smooth endcaps to control the wires and prevent snagging:
The central hole in the left cap passes 24 AWG silicone wires from the power supply, with 28 AWG silicone wires snaking down through the L-shaped rectangular cutouts along the extrusion to the LED module’s solder pads.
The model includes built-in support:
Assuming the curved ends didn’t need support / anchors holding them down turned out to be completely incorrect:
Fortunately, those delicate potato chips lived to tell the tale and, after a few design iterations, everything came out right:
The “connector”, such as it is, serves to make the light bar testable / removable and the ballast resistor tweakable, without going nuts over the details. The left side is an ordinary pin header strip held in place with hot melt glue atop the obligatory Kapton tape, because the heatsink doesn’t get hot enough to bother the glue. The right side is a pair of two-pin header sockets, also intended for PCB use. The incoming power connects to one set and the ballast resistor to the other, thusly:
The diagram is flipped top-to-bottom from the picture, but you get the idea. Quick, easy, durable, and butt-ugly, I’d say.
The next step was to mount it on the sewing machine and steal some power, but that’s a story for another day.
The relevant dimensions for the aluminum extrusion:
The OpenSCAD source code as a GitHub Gist:
Definitely not a vacuum tube:
The LED holder is identical to the Pirhana holder, with a 10 mm diameter recess punched into it for the SK6812 PCB:
The 3.6 V (and declining) power supply may not produce as much light from the SK6812 LEDs, but it’s entirely adequate for anything other than a well-lit room. The 28 AWG silicone wires require a bit of careful dressing to emerge from the holes in the radome holder:
The firmware cycles through all the usual colors:
A pair of tensilized 22 AWG copper wires support the Pro Mini between the rear struts. The whole affair looks a bit heavier than I expected, though, so I should reduce the spider to a single pair of legs with a third hole in the bottom of the LED recess for the data wire.
The OpenSCAD source code needs some refactoring and tweaking, but the Pirhana LED solid model version of the battery holder should give you the general idea.
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 …
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.
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:
[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:
Alas, the recessed letters become lost in their perimeter threads:
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:
Which looks OK in the real world, too:
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:
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.