Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
As you might expect by now, I harvest various bits & pieces from the PCs falling off the trailing edge of my assortment. The bag of obsolete DRAM recently floated to the top of the heap:
DRAM Assortment – overview
Half a gig of ECC RAM from what might have been a fire-breathing Pentium Pro box:
DRAM Assortment – 256 MB ECC
The PCBs along the top apparently filled vacant memory slots.
Some 32 and 64 MB DRAM from a few IBM laptops I turned into picture frames:
DDR2 DRAM in assorted sizes & speeds:
DRAM Assortment – PC2 DDR
PC133 DDR DRAM, with four sticks of 1 GB PC3 along the bottom:
DRAM Assortment – PC133
If you look closely, you may see something you can use. No reasonable offer refused …
The Mini-Lathe DROs eat a 390 alkaline coin cell a year, more or less:
Mini-Lathe DRO – battery life
The other DRO’s cell was 10 mV higher, so it might have survived another few weeks. I’ll call it a year, as the OEM cells failed half a year after I got the thing and these are the second set.
The last time I did this, I wedged a thin foam sheet below the display PCB to put a bit more pressure on the (+) contact tab sticking down from the middle of the plate:
Mini-Lathe DRO – battery compartment
The (-) contact is a pad on the PCB below the battery compartment. The glaring metal reflector is part of the curved cell retainer.
lsusb
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 248a:ff0f
Bus 001 Device 007: ID 058f:9410 Alcor Micro Corp. Keyboard
Bus 001 Device 006: ID 047d:1020 Kensington Expert Mouse Trackball
Bus 001 Device 005: ID 046d:c508 Logitech, Inc. Cordless Trackball
Bus 001 Device 003: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 006: ID 05e3:0748 Genesys Logic, Inc.
Bus 004 Device 005: ID 0480:a202 Toshiba America Inc Canvio Basics HDD
Bus 004 Device 004: ID 0bda:0411 Realtek Semiconductor Corp.
Bus 004 Device 003: ID 0451:8041 Texas Instruments, Inc.
Bus 004 Device 002: ID 0bda:0411 Realtek Semiconductor Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 006: ID 256c:006d
Bus 003 Device 004: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 003 Device 003: ID 0451:8043 Texas Instruments, Inc.
Bus 003 Device 002: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Yes, the space normally occupied by the product description is blank. The first blank description comes from a generic wireless keypad’s USB receiver; the 0x248a Vendor ID claims be Maxxter, a step down from the usual Logitech ID rip, and its 0xff0f Device ID looks bogus to me, too.
The 0x256c Vendor ID isn’t in the online databases yet, but some grepping found it in /lib/udev/rules.d/65-libwacom.rules:
Note, however, that the Device ID is 0x006e, where the upgraded V2 tablet is 0x006d; I have no idea why the number goes down as the version goes up. Change all instances of the former to the latter.
Even though the Wacom driver can apparently handle the older H610Pro, the V2 tablet’s buttons were missing in action.
xsetwacom --verbose set "HUION Huion Tablet Pen stylus" MapToOutput "DP-1"
The various buttons still need configuration, although that’s in the nature of fine tuning. The top three buttons are 1, 2, 3, with the rest tagging along at 8 through 12. They take trendy gray-on-black labeling to an absurd limit:
Huion H610Pro V2 – embedded gray-on-black buttons
That’s with intense overhead lighting shining into the buttons and lighting up the lower-surface iconography. In normal light, they’re shiny black disks with invisible legends and, no, they’re not backlit.
The overall button-tweaking syntax:
xsetwacom set "HUION Huion Tablet Pad pad" button 12 key whatever
Where whatever comes from the list in /usr/include/X11/keysymdef.h, per the doc in man xsetwacom and a list of possibilities from:
xsetwacom --list modifiers "HUION Huion Tablet Pad pad"
For example, this causes the bottom button to spit out a question mark:
xsetwacom set "HUION Huion Tablet Pad pad" button 12 key shift /
It’s not obvious changing the buttons from their default button numbers to anything else makes any sense; just tweaking individual programs to map those numbers into useful actions should work better.
(*) It has a “battery-free” stylus which, to my way of thinking, is a major selling point.
The O-ring replacement kit includes a pair of nylon (?) split rings which should provide bearing surfaces for the spout, but the upper ring sits in a groove putting its OD almost flush with the column:
Faucet column
This may be tolerance creep or just a design screwup, but the spout squashes the O-ring much more than (IMO) it should and wears it out entirely too soon.
This time around, I cut a strip of 0.4 mm thick polypropylene (from the Big Box o’ Clamshell Packages) long enough to wrap around the column and narrow enough to fit inside the groove, with the split ring holding it in place. The strip expands the ring’s OD to just barely fit inside the spout, so the spout now bears mostly on the ring, not the O-ring.
Despite measuring the groove OD and the spout ID, I had to cut-and-try several strips to find the proper thickness. Your mileage will certainly differ.
The spout now turns smoothly and freely, without leakage. We’ll see whether the new O-rings last longer than before.
The far end has a 2.5 mm hex driver, although I’ve never encountered a nut for an M1×0.25 screw in the wild. It doesn’t fit an 0-80 nut and gulps 00-90 nuts, so it’s definitely hard metric.
My collection of glasses required an aggregate two turns of tightening, which prompted dBm to remind me of threadlock.
During an evening KP session, the kitchen faucet handle jammed at the clockwise (hottest) end of its travel and refused to turn; it continued to move vertically and I turned off the water. This had happened before, so I knew roughly what to expect:
The pointer on the red hot limit safety stop ring should be aimed just right of the front screw, at the 0 position producing maximum hotness. The scale reads backwards, perhaps in units of increasing safety.
In that position, the ring prevents the valve core from turning counterclockwise, which explains the symptoms. With the water turned off (at the ball valves in the basement) and the valve stub tilted vertically, the ring popped loose (it shouldn’t move on its own) and exposed the problem:
Am Std Elite Faucet – wrecked hot limit splines – as found
Neither Mary nor I recall applying that much force to the handle, but ya never know.
The flanges protruding from the stem prevent you from removing the ring, but a pair of small diagonal cutters will chop right through the plastic. If you’re one of the six people depending on the limit stop to keep the water temperature under control, you probably don’t want to cut the ring out; I have no suggestions on how to repair it.
It’s obvious the splines won’t ever be the same again:
Am Std Elite Faucet – wrecked hot limit splines – detail 1
The ring has two sets of splines and they’re both wrecked:
Am Std Elite Faucet – wrecked hot limit splines – detail 2
With the ring out of the way, it’s easy to see the trunnion shaft has moved leftward:
Am Std Elite Faucet – misaligned pivot shaft
There’s essentially no clearance between the shaft and the ring, so it was rubbing against the ring, as evidenced by the red debris left behind when I tapped it to the far end of its travel:
Reassemble in reverse order and it works fine again.
I expect the shaft will resume moving leftward and eventually jam in the notch, probably after abrading the white plastic, but I don’t see how to lock it in place.