Posts Tagged Repairs

Blue Gauntlet Fencing Helmet Ear Grommet

Our Larval Engineer practiced fencing for several years, learning the fundamental truth that you should always bring a gun to a knife fight:

Fencing - taking a hit

Fencing – taking a hit

It’s time to pass the gear along to someone who can use it, but we discovered one of the ear grommets inside the helmet had broken:

Blue Gauntlet M003-BG Helmet - broken ear grommet

Blue Gauntlet M003-BG Helmet – broken ear grommet

The cylinder in the middle should be attached to the washer on the left, which goes inside the helmet padding. It’s a tight push fit inside the washer on the right, which goes on the outside of the padding. Ridges along the cylinder hold it in place.

Being an injection-molded polyethylene part, no earthly adhesive or solvent will bother it, soooo… the solid model pretty much reproduces the original design:

Fencing Helmet Ear Grommet - show

Fencing Helmet Ear Grommet – show

The top washer goes inside the padding against your (well, her) ear, so I chamfered the edges sorta-kinda like the original.

There are no deliberate ridges on the central cylinder, but printing the parts in the obvious orientation with no additional clearance makes them a very snug push fit and the usual 3D printing ridges work perfectly; you could apply adhesive if you like. The outside washer has a slight chamfer to orient the post and get it moving along.

The posts keep the whole affair from rotating, but I’m not sure they’re really necessary.

Printing a pair doesn’t take much longer than just one:

Fencing Helmet Ear Grommet - build

Fencing Helmet Ear Grommet – build

It doesn’t look like much inside the helmet:

Blue Gauntlet M003-BG - replacement ear grommet - installed

Blue Gauntlet M003-BG – replacement ear grommet – installed

The OpenSCAD source code as a gist from Github:

,

6 Comments

Logitech M305 Mouse Switch Cleaning

While installing Mint on the Lenovo Q150, I discovered that the right button on the (long disused) Logitech M305 wireless mouse wasn’t working. After replacing the batteries (always check the batteries), it still didn’t work, so I peeled the four slippery feet off the bottom, removed the screws, and confronted the interior:

Logitech M305 mouse - interior

Logitech M305 mouse – interior

Much to my surprise, the button switches had removable covers:

Logitech M305 mouse - switch disassembly

Logitech M305 mouse – switch disassembly

I put a minute drop of DeoxIT Red on a slip of paper, ran it between both pairs of contacts, removed a considerable amount of tarnish, reassembled in reverse order, and it’s all good again.

The glue on the back of the slippery feet didn’t like being peeled off, so I expect they’ll fall off at some point.

It’s much easier to drive a GUI with three functional buttons…

[Update: Long-time commenter Raj notes:

I always had problem with the middle button. I have replaced them a few times and learnt that they come with different operating pressures. The soft ones are hard to come by. I found an alternate in the PTT switches on Yaesu handies in my junk.

That’s the blocky switch to the left of the shapely wheel cutout.]

8 Comments

Gorilla Glue: Cured in the Bottle

So the dishwasher ate another rack protector, which happens a few times a year. I’m getting low on spares, so maybe it’s time to run off a few in cyan PETG to see if the cute support structure will still be removable:

Dishwasher rack protector - support model

Dishwasher rack protector – support model

Anyhow, this time I used urethane glue, because the last of the acrylic caulk went into another project. I store the Gorilla Glue bottle upside-down so the entire top doesn’t cure solid, but:

Gorilla Glue - cured in bottle

Gorilla Glue – cured in bottle

Usually, it’s just cured in the snout. This time, the layer across the bottom was a few millimeters thick and the glue below seemed rather thick. I tossed the solid lump, slobbered a dab of thick goo on the dishwasher rack, jammed the new protector in place, replaced the cap, and declared victory.

That’s why I no longer buy that stuff in The Big Bottle…

 

,

12 Comments

Hard Drive Platter Mood Light: Correct Phase Timing

As noted earlier, the timing for a π/16 phase delay works out to

218 steps = (π/16) * (1 cycle/2π) * (7 * 1000 step/cycle)

which amounts to a delay of 5.45 s = 218 step * 25 ms/step. That means a color should appear on the top platter 11 s after it appears on the bottom platter:

Mood Light - pi over 16 phase - composite

Mood Light – pi over 16 phase – composite

But when I actually got out a stopwatch and timed the colors, the bottom-to-top delay worked out to a mere 3.5 s…

After establishing that the steps ticked along at the expected 25 ms pace, the phase-to-step calculation produced the right answer, the increments were working as expected, I finally slept on the problem (a few times, alas) and realized that the increment happened in the wrong place:

for (int i=0; i < LEDSTRINGCOUNT; i++) { // for each layer byte Value[PIXELSIZE]; for (byte c=0; c > PIXELSIZE; c++) { // figure the new PWM values if (++Pixels[c].Step >= Pixels[c].NumSteps) {   //  ... from incremented step
            Pixels[c].Step = 0;
        }
        Value[c] = StepColor(c,-i*Pixels[c].PlatterPhase);
    }
    uint32_t UniColor = strip.Color(Value[RED],Value[GREEN],Value[BLUE]);
 
    for (int j=0; j < LEDSTRIPCOUNT; j++) {              // fill layer with color
        strip.setPixelColor(Map[i][j],UniColor);
    }
}

The outer loop runs “for each layer”, so the increment happens three times on each step, making the colors shift three times faster than they should.

Promoting the increments to their own loop solved the problem:

	MillisNow = millis();
	if ((MillisNow - MillisThen) > UpdateMS) {
		digitalWrite(PIN_HEARTBEAT,HIGH);
		
		for (byte c=0; c < PIXELSIZE; c++) { // step to next increment in each color if (++Pixels[c].Step >= Pixels[c].NumSteps) {
				Pixels[c].Step = 0;
				printf("Cycle %d steps %d at %8ld delta %ld ms\r\n",c,Pixels[c].NumSteps,MillisNow,(MillisNow - MillisThen));
			}
		}

		for (int i=0; i < LEDSTRINGCOUNT; i++) {				// for each layer
			byte Value[PIXELSIZE];
			for (byte c=0; c < PIXELSIZE; c++) {				//  ... for each color
				Value[c] = StepColor(c,-i*Pixels[c].PlatterPhase);		// figure new PWM value
//				Value[c] = (c == RED && Value[c] == 0) ? Pixels[c].MaxPWM : Value[c];	// flash highlight for tracking
			}
			uint32_t UniColor = strip.Color(Value[RED],Value[GREEN],Value[BLUE]);
			if (false && (i == 0))
				printf("L: %d C: %08lx\r\n",i,UniColor);
			for (int j=0; j < LEDSTRIPCOUNT; j++) {				// fill layer with color
				strip.setPixelColor(Map[i][j],UniColor);
			}
		}
		strip.show();

		MillisThen = MillisNow;
		digitalWrite(PIN_HEARTBEAT,LOW);
	}

And then It Just Worked.

Verily, it is written: One careful measurement trumps a thousand expert opinions.

Sheesh

(The WordPress editor wrecked these code snippets. I’m leaving them broken so WP can maybe fix the problem.) The problem isn’t fixed, but these are OK now… as long as I don’t unleash the “improved” editor on the post, anyway.

, ,

4 Comments

Forcing UDEV to Not Rename Network Adapters

I use System Rescue CD to repartition / backup / restore hard drive partitions, but a not-very-recent change to udev caused the familiar eth0 name to come up as something like enp0s26u1u2 on the Lenovo Q150. Which would be OK, but feeding either that or eth0 into net-setup causes it to fall over dead.

Avoiding that mess requires an incantation in the kernel boot parameters: select a main boot option, hit Tab, type net.ifnames=0 (with a leading space), and whack Enter to boot. Then good old eth0 appears where it should and everything works.

It’s annoying, but not quite enough to create a specialized SysRescCD image with that incantation preloaded.

Leave a comment

Squidwrench Vending Machine: OEM Wiring Diagram

An old vending machine in need of rebooting may provide fodder for some electronics tutorials at Squidwrench. To that end, here’s the OEM wiring diagram pasted inside the door:

SqWr Vending Machine - OEM Wiring Diagram

SqWr Vending Machine – OEM Wiring Diagram

That’s endured a perspective transformation and a bit of contrast stretching; it looks awful, but being able to view it without squatting inside the machine makes it much easier to read…

Each selector and motor cycle switch pair interact with the motor thusly:

Vending Machine - Switches and Motor Doodle

Vending Machine – Switches and Motor Doodle

All of the motors have one side connected directly to the 24 VAC power transformer. The wiring diagram shows a pair of transformers in parallel, which seems odd.

The Selector switches (an array of 30 on the front panel, with one broken that will surely call for some 3D printing) are in series, so the lowest-numbered one wins; the NO terminal of each Selector switch  goes directly to the control box. Pressing a switch connects the Red·Orange wire on the C terminal of the first switch to the control box on the same wire as the corresponding motor lead.

Assuming the Motor Cycle switch parks in the NC position, it will disconnect the Orange wire from the Orange·Black wire and connect it to the lower motor lead and the Select switch (which may or may not be pressed by then), although we don’t know the timing. There’s surely a cam on the motor shaft.

Some possibly relevant patents, found after a brief search with the obvious keywords:

5 Comments

Lenovo Q150 Restoration Utility

The general idea was to put the old Lenovo Q150 to work as a dedicated Superformula generator attached to the HP 7475A plotter: connect the serial cable, fire ’em up, and It Just Works. As part of the first pass, I installed Mint Linux atop an old Ubuntu install, got Python & Chiplotle set up, and That Just Works:

Lenovo Q150 with HP 7475A

Lenovo Q150 with HP 7475A

However, the Q150 sports a dual-core Intel Atom, underpowered even back in the day, that hasn’t gotten any peppier over the years. The Lenovo-installed Windows 7 pushed the CPU hard enough to require full-throttle fan whine, even at idle, and mysterious issues with memory usage (something involving a memory leak in svchost.exe or perhaps over-aggressive Windows Update prefetching) reduced performance to a crawl as the system paged its brains out to the 5400 RPM laptop-style drive (*). As part of this adventure, I figured I’d boot the Lenovo restore partition and burn Win 7 back to bedrock before installing Mint.

Turns out that the Lenovo restore utility doesn’t work when the drive has an unusual partition structure; it tells you to repartition the drive and try again. So I blew away the Ubuntu installation’s extended partition (containing swap, main, and spare partitions), then rebooted, only to discover that, of course, the missing partitions contain Grub’s later stages. Having previously wasted far too much time trying to resuscitate various half-dead Grubs, I created a fourth partition, installed Mint Linux (ignoring its strenuous objections about not having a swap partition) to refresh Grub, booted the Lenovo restore utility, and ended up at a raw Windows terminal emulator box atop a picture of some weird tropical greenery. Apparently the restore utility depends on something that got blown away during all the flailing around.

So, just for completeness, I shrank Mint a bit, added a swap partition, and got the results shown above. One core runs at 100%, probably dribbling bytes to the USB-to-serial adapter, but the thing runs much cooler. In this context, it should be noted, a 110 °F surface and 140 °F exhaust temperature counts as “cool”; the fan isn’t at full throttle, but it’s surprisingly noisy for a computer billed as a multimedia streaming device.

I actually have a complete backup of the original contents of all three partitions, so I could whack it back to mid-2011. Modulo, of course, resetting the actual partition sizes and positions and suchlike, which I’m sure will be vital to having the restore utility do its thing. Maybe that’s worthwhile just to remind me why it’s such a terrible idea.

(*) Blowing $50 on an SSD is so not happening, OK?

 

5 Comments