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.

Category: PC Tweakage

Remembering which tweaks worked

  • Kenmore 158: Useful Unicode Glyphs

    It turns out, for some reasons that aren’t relevant here, that I’ll be using the Adafruit Arduino LCD panel for the sewing machine control panel, at least to get started. In mulling that over, the notion of putting text on the buttons suggests using getting simple pictures with Unicode characters.

    Herewith, some that may prove useful:

    • Needle stop up: ↥ = U+21A5
    • Needle stop up: ⤒=U+2912
    • Needle stop down: ⤓ = U+2913
    • Needle stop any: ↕ = U+2195
    • Needle stop any: ⟳ = U+27F3
    • Needle stop any: ⇅ = U+21C5
    • Rapid speed: ⛷ = U+26F7 (skier)
    • Rapid speed: 🐇  = U+1F407 (rabbit)
    • Slow speed: 🐢 = U+1F422 (turtle)
    • Dead slow: 🐌 = U+1F40C (snail)
    • Maximum speed: 🏃 = U+1F3C3 (runner)
    • Bobbin: ⛀ = U+26C0 (white draughts man)
    • Bobbin: ⛂ = U+26C2 (black draughts man)
    • Bobbin winding: 🍥 = U+1F365 (fish cake with swirl)

    Of course, displaying those characters require a font with deep Unicode support, which may explain why your browser renders them as gibberish / open blocks / whatever. The speed glyphs look great on the Unicode table, but none of the fonts around here support them; I’m using the Droid font family to no avail.

    Blocks of interest:

    The links in the fileformat.info table of Unicode blocks lead to font coverage reports, but I don’t know how fonts get into those reports. The report for the Miscellaneous Symbols block suggested the Symbola font would work and a test with LibreOffice show it does:

    Symbola font test
    Symbola font test

    An all-in-one-page Unicode symbol display can lock up your browser hard while rendering a new page.

    Unicode is weird…

  • Always Remove Your Data Before Disposing of Your Hardware

    Surely you’ve seen the reports on the plumber who sold his Ford F-250 pickup, only to have it reappear on the Syrian front lines, recycled into an anti-aircraft gun platform:

    Mark-1 Truck Cannon in Syria
    Mark-1 Truck Cannon in Syria

    That’s the most spectacular example I’ve seen of what happens when you leave personal data on hardware that’s no longer under your control, but imagine what would happen if your junked hard drive wound up holding, oh, say, a few gigabytes of kiddy porn, along with your old letters and spreadsheets.

    A visit from the DHS agents would look downright appealing.

    You could always scrub the platters clean:

    Scrubbed hard drive platters
    Scrubbed hard drive platters

    The gun has shrapnel shields and might actually be an anti-aircraft gun, but it’s obviously pounding ground-level targets…

  • Iomega 500 GB NAS Drive for Helmet Camera Storage

    I recently exhumed an Iomega 500 GB Home Network Hard Drive (model MDHD-500-N) from the Big Box o’ Drives, with the intent of dumping video files from the Sony HDR-AS30 helmet camera thereupon.

    Remember Iomega of ZIP Drive fame? Seems EMC Borged ’em a while back, collided with Lenovo, discarded all the old hardware support, and that’s the end of that story.

    Exhuming the setup password from my backup stash wasn’t worth the effort, so I experimentally determined that holding the Reset switch closed while turning the drive on blows away the existing configuration. It woke up, asked for an IP address, got 192.168.1.52 from the DHCP server (you can find that by checking the router’s tables), and popped up the administration console at 192.168.1.52:80 as you’d expect.

    The userid will always be admin, but you can change the password from admin to whatever you like; you may safely assume I have done somewhat better than what you see below.

    Twiddling the configuration through the IOmega web-based console:

    • Device name: IOMEGA-500MB (for lack of anything more creative)
    • Group name: WHATSMYNET
    • Password: not-admin
    • Drag the date/time into the current millennium
    • Time Zone: GMT-5:00
    • Time Server: 0.us.pool.ntp.org
    • Static IP: 192.168.1.10 (suitable for my network)
    • Gateway & DNS as appropriate
    • Windows File Sharing enabled for the PUBLIC directory
    • FTP turned off
    • Sleep time: 10 minutes

    Changing either the IP address or the password requires logging in again, of course.

    I reformatted the drive, just to be sure.

    Then, after a bit of Googling to remember how all this works…

    A line in /etc/hosts (left over from the last time I did this) gives the new static IP address:

    192.168.1.10 nasty

    Install the cifs-utils package to enable mounting the drive.

    Create a mount point:

    sudo mkdir /mnt/video

    Create a file (/root/.nas-id) holding the super-secret credentials used to gain access to the drive:

    domain=WHATSMYNET
username=ed
password=not-admin

    Then restrict the file to the eyes of the root user:

    sudo chmod 700 /root/.nas-id

    It’s not clear that the username or domain really make any difference in this situation, but there they are.

    Define where and how to mount the network drive with a new line at the bottom of /etc/fstab, which refers to the aforementioned super-secret credentials file:

    //nasty/PUBLIC  /mnt/video      cifs    noauto,uid=ed,credentials=/root/.nas-id 0 0

    Mounting it with my userid gives the shared directories & files proper permissions for me (and nobody else, not that anybody else around here cares).

    So the manual mounting process looks like this:

    sudo mount /mnt/video

    Adding the user mount option would eliminate the sudo, but manual mounting won’t be necessary after a normal boot when the automagic startup script does the deed.

    The drive must have the noauto attribute to prevent the upstart Pachinko machine from trying to mount the network drives before the network comes up. Actually mounting the drive at the proper time requires an additional line in /etc/init/local.conf:

    description "Stuff that should be in /etc/rc.local"
author "Ed Nisley - KE4ZNU"

start on (local-filesystems and net-device-up IFACE=em1)
stop on shutdown

emits nfs-mounted

script

logger Starting local init...

logger Mounting NFS (and CIFS) filesystems
mount /mnt/bulkdata
mount /mnt/userfiles
mount /mnt/diskimages
mount /mnt/music
mount /mnt/video
initctl emit nfs-mounted
logger Ending local init

end script

    The reason the drive wound up in the Big Box o’ Hard Drives was its lethargic transfer speed; copying a 4 GB video file from either the MicroSDXC card (via an SD adapter) or the previous 750 GB USB-attached hard drive to the IOmega NAS trundles along at a little over 6 MB/s. The camera stores 25 Mb/s = 3 MB/s of data in 1080p @ 60 fps, so figure 1/2 hour of copying per hour of riding. The USB drive can write data from the aforementioned MicroSDXC card at 18 MB/s, so the card and USB interface aren’t the limiting factors.

    I’m not (generally) in a big hurry while copying files from the camera’s SD card, because that’s now automated:

    #!/bin/sh
thisdate=$(date --rfc-3339=date)
echo Date is [$thisdate]
# IOmega NASalready mounted as /mnt/video in fstab
mkdir /mnt/video/$thisdate
sudo mount -o uid=ed /dev/sdb1 /mnt/part
rsync -ahu --progress /mnt/part/MP_ROOT/100ANV01/ /mnt/video/$thisdate
if [ $? -eq 0 ] ; then
 rm /mnt/part/MP_ROOT/100ANV01/*
 sudo umount /mnt/part
fi

    I’ve been discarding the oldest month of videos as the USB hard drive fills up, which will happen a bit more often than before: the drive’s 466 GB can hold barely 35 hours of ride video.

  • Trust Multimedia Mouse: Gummy Rubber

    While looking for something else, I found the old Trust Multimedia Mouse and discovered its nice grippy rubber surfaces had become adhesive slime. Graduated efforts with water, rubbing alcohol, and denatured alcohol being unavailing, I finally hit it with xylene and that did the trick:

    Degummed Trust Mouse
    Degummed Trust Mouse

    Of course, xylene also wiped away the fancy button markings and irretrievably scarred the surface, but at least I can pick the mouse up without having it stick to my hand. Not that I pick it up that often, obviously.

    Several other gadgets have a similar grippy finish, so now I know what to do when it turns gummy: throw the gadgets out…

  • ATX Power Supply: System Board Connector Bracket

    The GX270 case contains a perfectly serviceable ATX power supply that can power all the bits & pieces that don’t run directly from the AC power line. I torched the connector off the system board, but there’s no practical way to mount it standing up through the prototyping board I’m using for the low voltage electronics. This bracket surrounds that connector and holds it at right angles to the board, with a pair of screws clamping it in place:

    ATX Connector Bracket - front
    ATX Connector Bracket – front

    I invoked the shade of Willy McCoy, slashed the outside of the connector with a razor knife, buttered it up with epoxy, and shoved it flush inside the adapter. That messy epoxy bead around the joint should prevent it from pulling out to the front:

    ATX Connector Bracket - rear
    ATX Connector Bracket – rear

    The solid model looks like you’d expect:

    ATX Connector Mount
    ATX Connector Mount

    In the unlikely event you need one, make sure the slot clears the locking clip on your ATX connector, as they differ between (at least) the 20 and 24 pin versions. This is actually a split 20/24 connector, with the smaller connector terminating elsewhere to power the LED strips.

    The OpenSCAD source code:

    // ATX power supply connector mounting bracket
// Ed Nisley - KE4ZNU - September 2014

//- Extrusion parameters must match reality!

ThreadThick = 0.20;
ThreadWidth = 0.40;

HoleWindage = 0.2;			// extra clearance

Protrusion = 0.1;			// make holes end cleanly

AlignPinOD = 1.70;			// assembly alignment pins: filament dia

function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);

//----------------------
// Dimensions

Screw = [3.5,7.0];						// mounting screws
OD = 0;
HEAD_OD = 1;

Wall = 3.0;

ATX = [43.5,9.75,12.0];					// connector outline

Shell = ATX + [2*(2*Wall + Screw[OD]),2*Wall,0.0];	// mount outline

Latch = [5.0,5.0,7.0];							// latch overlay

ScrewOC = ATX[0] + Screw[OD] + 2*Wall;

echo(str("Screw OC: ",ScrewOC," mm"));

//----------------------
// Useful routines

module PolyCyl(Dia,Height,ForceSides=0) {			// based on nophead's polyholes

  Sides = (ForceSides != 0) ? ForceSides : (ceil(Dia) + 2);

  FixDia = Dia / cos(180/Sides);

  cylinder(r=(FixDia + HoleWindage)/2,
           h=Height,
           $fn=Sides);
}

module ShowPegGrid(Space = 10.0,Size = 1.0) {

  RangeX = floor(100 / Space);
  RangeY = floor(125 / Space);

	for (x=[-RangeX:RangeX])
	  for (y=[-RangeY:RangeY])
		translate([x*Space,y*Space,Size/2])
		  %cube(Size,center=true);

}

ShowPegGrid();

difference() {
	translate([0,0,Shell[2]/2])						// mount shell
		cube(Shell,center=true);
	translate([0,0,ATX[2]/2])					// connector shell
		cube(ATX + [0,0,2*Protrusion],center=true);

	translate([0,(Latch[1]/2 + ATX[1]/2 - Protrusion),(-Latch[2]/2 + Shell[2])])
		cube(Latch + [0,Protrusion,Protrusion],center=true);

	for (i=[-1,1])
		translate([i*ScrewOC/2,(Shell[1]/2 + Protrusion),Shell[2]/2])
			rotate([90,0,0])
				PolyCyl(Screw[OD],(Shell[1] + 2*Protrusion));

}

  • Dell Optiplex GX270 Power Control PCB Connections

    The general idea is to gut an old Dell Optiplex GX270 and stuff the high-voltage parts of the sewing machine controller inside a well constructed and solidly grounded metal shield inside a not-too-ugly plastic box. It’d be nice to reuse the power control button and status LEDs on the front panel…

    The few parts on the front of the through-hole board:

    Dell Power Button PCB - component
    Dell Power Button PCB – component

    The copper side, with annotations:

    Dell Power Button PCB - copper
    Dell Power Button PCB – copper

    The red tracer on the ribbon cable goes to Pin 1, which is a blind key on the PCB.

    The LEDs do not have ballast resistors, so those must go on a circuit board somewhere else.

    The connections:

    16 14 12 10 8 6 4 2
    Gnd nc nc nc nc HD+ HD- Button+
    Gnd nc Gnd Pwr Y+ Gnd Pwr G+ Gnd Key
    15 13 11 9 7 5 3 1

     

  • Xubuntu: Setting Up a Solid State Drive

    It turns out that the clever idea of moving the swap partition to a USB flash drive had no effect whatsoever; the UI continued to freeze up during OpenSCAD compiles and suchlike, with the drive activity light on solid and not much in the way of swap activity. Sooo, I wondered what would happen with the /tmp directory on non-rotating memory.

    Then I spotted a sale on a Samsung 840 EVO 120 GB solid state drive, which seemed like it might improve almost everything in one swell foop. That’s a tiny drive, at least by contemporary standards, but all my data files live downstairs on the file server, so the desktop drive holds just the Xubuntu installation.

    It’s worth noting that SSDs tend to fail suddenly and catastrophically, so that if the only copy of your data is on that drive, there is no recovery. In this case, I’d lose some configuration that changes with every installation, a few locally installed / compiled-from-source programs, and little else.

    The nice thing about transferring a Linux installation: boot a live CD image (I used Ubuntu 14.04LTS, the same as the desktop box), copy the files to the new drive, set up Grub, and you’re back on the air. That recipe worked fine, although I used rsync -au to copy the files and then updated /etc/fstab with the SSD’s new UUID (rather than duplicate a supposedly unique ID).

    The Grub recipe does require a bit of delicate surgery, so I removed the OEM hard drive and rebooted the live CD image before doing this. If the SSD fell victim to a finger fumble, I could just start over again:

    sudo mount /dev/sda1 /mnt
for f in dev proc sys usr ; do sudo mount --bind /$f /mnt/$f ; done
sudo chroot /mnt
sudo update-grub
sudo grub-install /dev/sda
sudo grub-install --recheck /dev/sda
exit
for f in dev proc sys usr ; do sudo umount /mnt/$f ; done
sudo umount /mnt

    Then reboot from the SSD and It Just Worked.

    Dropbox and DigiKam noticed the UUID change and asked for advice; there’s no need for re-registration, re-activation, or re-authorization.

    The overall time from boot to login isn’t much shorter, because of the tedious delay while the network and the NFS shares get up & running, but the desktop UI startup zips right along.

    The same OpenSCAD compile that previously brought the UI to a halt has no effect, so I hereby declare victory. I think the complex solid models that used to take forever will see much the same speedup.

    The Dell hard drive (an ordinary 7200 RPM 3.5 inch brick) lies abandoned in place under the fancy black shroud; the Optiplex 980 layout butts the drive’s right-angle SATA connectors hard against the CPU heatsink and offers no spare SATA power connectors. There was just enough room to wedge the SSD above the PCI connectors, where it won’t get into any trouble:

    Samsung 840 EVO SSD in Optiplex 980
    Samsung 840 EVO SSD in Optiplex 980

    The hard drive contains the never-used Windows 7 partition and the corresponding recovery / diagnostic partitions; keeping the drive with the Optiplex chassis seems like a Good Idea.