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.
Seen from the Walkway Over the Hudson during a Moonwalk:
Taken with the Pixel XL braced on the railing. It has a good camera, but good low-light photography requires bigger pixels, more lens, and less compression.
The bright white block just to the right of the left tower comes from construction lighting in the new Vassar hospital building.
So this happened:
As far as I can tell, the Crucial M5500 SSD in that PC (an off-lease Dell Optiplex 760) stopped being a SATA hard drive, although it seems to work OK when jammed in a USB adapter.
So I picked up a new-to-me Optiplex 9020 with Windows 8.1 on an SSD, shrank the partition, tried to install Xubuntu 18.04, fat-fingered the UEFI password dance, reinstalled Windows from the SSD’s recovery partition, and got this display after a while (clicky for more dots):
After letting it stew in its own juices during supper, I forced it off (pushed the power button until it died), restarted, got through the UEFI dance, and it now seems All Good. I made recovery DVDs (remember DVDs?), both before and after the fumbled Xubuntu installation, but didn’t need them.
I expect we’ll never boot Windows 8.1 again, but it’s there Just In Case.
The Intertubes occasionally clog up while streaming low-bit-rate audio, for no reason I can fathom, leading to discontent in the User Community when it affects quiet classical music played in the dead of night. Given that the stream from far-off Switzerland consists entirely of public-domain performances, I set up Raspbian Lite on a headless Raspberry Pi 1 Model B+ in a spot where it won’t be disturbed:
Connecting to the Pi with a screen session, so as to allow disconnection & reconnection without anguish, I fired streamripper thusly:
streamripper http://relay.publicdomainproject.org/classical.mp3.m3u -xs2 -o larger -u "MPlayer2" -m 30 -r -R 6 --with-id3v1
The -r -R 6 options set up a relay stream on http://ripper.local:8000 for the benefit of my local streamers, so only one trickle of bits crosses the Atlantic.
The total CPU load amounts to a percent or two, tops, so a single-core 700 MHz Pi has no trouble keeping up.
Because streamripper slings bits in more-or-less real time, the local servers don’t get any track title data when they start up, so the OLED display doesn’t update immediately. This is less of a problem than you might think, as we’re generally not hanging on the display to find out exactly which Vivaldi bassoon concerto is playing.
Given a suitable collection of tracks, I’ll set up an icecast server as the classical music “station” for the streamers, but that’s an adventure for another day. I also want to splice separate movements back into continuous symphonies, the way they’re suppose to be heard.
The rod along the left side of our miniblinds turns a shaft spanning the length of the housing which pulls-and-releases three pairs of cords tilting the blades, with one roller for each pair. The cords loop over, pass under, and are secured to a tab on the roller with metal ferrules, thusly:
One day, the middle section of all the blades on one miniblind stopped tilting, prompting this discovery:
The correct solution is, of course, to replace the entire miniblind, but our 1955 window frames don’t match up well with contemporary miniblind hardware and I was unwilling to reinvent that particular wheel for this occasion.
So I laid the cords in place, put the broken tab atop them, and held the mess together with a strip of the obligatory Kapton tape:
Easing some epoxy under the tab and soaking the cords atop the tape held everything together in approximately the original layout:
Two days after I reinstalled the miniblind, a second roller broke and was restored by a similar treatment. While I had the thing on the bench clamped in the bench vise, I preemptively slobbered epoxy on the intact roller in the hope of reinforcing it.
So far, so good!
A recent Squidwrench meeting produced a treasure trove of discarded LED lighting, including a shoplight-style fixture in a narrow, finned aluminum extrusion. It was in “known-bad” condition, so I extracted the four LED panels, connected each one to a widowmaker cord, and determined I had two good ones, a mostly working one sporting some dead LEDs, and a corpse.
The working panels showed the power supplies produced about 19 V across two parallel strings of six LEDs, with each string running at 350 mA for a total of 700 mA = 13 W. I wired up a quartet of 6 Ω power resistors to check out the power supplies from the suspect panels:
The supply in the background is truly dead. I can’t tell whether it killed the LEDs or the gaggle of failing LEDs dragged it down with them.
Some multimeter probing revealed enough live LEDs to restore the partially working panel. A rather sweaty interlude at the SqWr hot-air rework station transplanted the good LEDs, whereupon combining it with the live supply gave me a third fully functional panel:
I did the test firing in the Basement Laboratory, because I’m nowhere near crazy enough to deploy a widowmaker line cord on the SqWr Operating Table in public.
I bandsawed the last working LED from the gutted donor panel:
The SMD LEDs mount on traces applied to and electrically insulated from the aluminum sheet, so unsoldering them required way more heat than you (well, I) might expect at first glance. A snap-on condenser lens over each LED concentrates the light into a nice cone, producing a narrow sheet of light from each panel.
The elaborate aluminum extrusion seems much too heavy for the individual panels, but those open-frame supplies definitely need more than casual protection. Now that LEDs are more common than when these panels came off the assembly line, I should probably replace the supplies with enclosed constant-current drivers and be done with it.
GIMP seems to set up its menu structure during installation, with sensible, if lengthy, hardcoded addresses and menu names for your remote (network) scanner based on its host and USB port location:
(proc-def "xsane-net-3a-plex760-2e-local-3a-genesys-3a-libusb-3a-002-3a-002" 2 … snippage … (menu-path "<Image>/File/Create/Acquire/XSane/net:plex760.local:genesys:libusb:002:002")
Should you happen to plug the scanner into a different PC or USB port, perhaps while replacing a failed system, then you must change those hideous strings all by yourself.
So, for example, plugging the aforementioned scanner into a randomly chosen USB port on a new-to-me Dell Optiplex 9020 showing up as plex9020.local on the network produces this identification string:
[ed@shiitake ~]$ scanimage -L device `net:plex9020.local:genesys:libusb:003:003' is a Canon LiDE 120 flatbed scanner
GIMP’s ~/.gimp-2.8/pluginrc file defines the device address:
(proc-def "xscanimage-net-3a-plex9020-2e-local-3a-genesys-3a-libusb-3a-003-3a-003" 2
The -3a- string seem to be an escape sequence for the colon symbol separating parts of the address. Why we need so many different escape sequence standards mmm escapes me at the moment.
The menu-path string defines the text appearing in the GIMP UI, so you can use a somewhat more readable generic name:
(menu-path "<Image>/File/Create/Acquire/xscanimage/Plex9020-scanner")
The ~/.gimp-2.8/menurc file contains GIMP’s keyboard accelerators, which (apparently) must match the revised proc-def strings:
; (gtk_accel_path "<Actions>/plug-in/xscanimage-net-3a-plex9020-2e-local-3a-genesys-3a-libusb-3a-003-3a-003" "")
A keyboard accelerator for the scanner wouldn’t save any appreciable amount of time or effort, so (I think) the semicolon marks it as Disabled in the UI.
It is remarkably easy to make a one-character typo while doing this, particularly if you’re using sed to change All. The. Strings. at once.
There is, AFAICT, no documentation, which almost certainly means I don’t know where to look.
The side of our house seems to attract Organ Pipe Mud Dauber Wasps during nesting season.
One pair of wasps built this impressive structure behind the patio door, beside the bathroom window:
The female wasp built six tubes over the course of an August week, carrying blobs of mud the size of her head and abdomen from sources about 30 seconds away (1 minute round trip). Each blob produces half of one serration around the tube, with a seam running down the middle, and requires 20 seconds to smooth into place. We got tired just watching her!
Each tube has many compartments, each containing a wasp larva and a paralyzed spider, with a mud cap inside the end:
We watched the wasps attack, sting, and remove spiders of a specific size from the corners of our window frames.
The young wasps in the innermost tube may not make it out alive, because they must chew through at least one outer tube before flying away:
Perhaps layering the outer tubes around a central tube makes for a more compact and durable nest, with the possible sacrifice of offspring in the center.
The new wasps will likely emerge next spring.
The Smell of Molten Projects in the Morning 