Archive for September, 2018
I managed to snag a cargo pocket on the under-sink drawer knob in the Black Bathroom:
Did a job on the pocket, too, although after Mary was done with it, you’d never know.
With that much of a bend in the screw, the knob left a nasty divot in the drawer front requiring a layer of wood-filled epoxy:
I sanded it more-or-less flush with the surface, taking great pains to not scuff the surrounding paint. A similar layer fills the corresponding divot under the screw head inside the front.
Despite appearances, only about 1/8 inch of the epoxy peeked around the knob, so I painted it black with a Sharpie, ran the knob onto the screw, and declared victory:
I’ll (try to) (remember to) stand further back from the knob …
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:
streamripper http://relay.publicdomainproject.org/classical.mp3.m3u -xs2 -o larger -u "MPlayer2" -m 30 -r -R 6 --with-id3v1
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-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
-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.
menu-path string defines the text appearing in the GIMP UI, so you can use a somewhat more readable generic name:
~/.gimp-2.8/menurc file contains GIMP’s keyboard accelerators, which (apparently) must match the revised
; (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.