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.

Tag: Improvements

Making the world a better place, one piece at a time

Improved Pilot InstaBoost Jumpstarter Clamps

The Sienna now spends all its time sitting outdoors in an apartment parking lot and gets even less driving (hence, battery-charging) time than we used to give it. Fortunately, Santa being my kind of guy, our Larval Engineer received a Pilot InstaBoost jumpstarter, which is basically a 10 A·h / 40 W·h lithium battery with husky plug & socket connectors, a pair of 10 AWG wires, and big alligator clamps. The package claims a 400 A peak discharge rate, but the tiny inscription on the back of the case reports 200 A; either of those seems mmmm somewhat optimistic to me.

The customer reviews suggest that the plastic battery clamp handles feature a crappy hinge joint which disintegrates under moderate stress on a cold winter night, firing the spring into the nearest snowbank and rendering the clamp completely useless. The joint consists of a plastic post on each side of the inner handle that protrudes into a hole in the outer handle:

Battery Clamp – original joint

I assigned her some Mandatory Quality Shop Time to improve the joint. She found some brass tubing that fit the existing hole and cut two pieces to length:

Battery Clamp – cutting brass tube

A 1 inch stainless screw was just barely long enough (that’s Loctite Red in the nut), but the end result certainly looks durable enough:

Battery Clamp – improved joint

It’s along the same lines as the improvement I applied to my old Park Tool MTB-7 Rescue Tool.

Apart from that, the clamps look pretty good. There’s even a husky braid between the two jaw pads, ensuring at least one reasonably low resistance joint to the battery post:

Battery Clamp – jaw strap

With a bit of luck, we’ll never know how well it works as a jumpstarter. She can use the USB port to keep her phone charged, which may provide enough motivation to keep the thing topped up and ready for use…

[Update: two days after this post went live, someone found it by searching for:

how to repair clamps pilot instaboost 400

You have been warned!]

2014-12-28
Kenmore 158: Recalibrated Optoisolator Drive

Because the motor will draw more current during pulsed operation, the ET227 needs more base drive. The existing circuit topped out around 2.5 A, so I reduced the current sampling resistor by a bit:

Optoisolator Driver

If you care about the exact current, you’d use a 1% resistor, but if you care about the current, you’ll be doing closed-loop feedback to compensate for the transistor gain variations. Compared to those, the resistor doesn’t matter.

Running the MCP4725 DAC through its range produces a nice graph:

Current Calibrate – DAC – 270k Hall 2.7k opto

The X axis comes from the Tek Hall-effect current probe, so the numbers don’t depend on the ferrite toroid & differential amp calibration. They do, of course, require a bit of eyeballometric calibration to extract the flat top from the waveform, as shown by this old waveform:

Motor current – ADC sample timing

Ya gotta start somewhere.

The linear fit to those dots gives the DAC value required to produce the observed current, at least for these particular transistors at whatever temperature they’re at in a rather chilly Basement Laboratory.

Of course, the observed current tops out at 1.2 A: the motor’s peak current during normal linear operation. The line looks so pretty that I’ll assume it continues upward to the maximum 12-bit DAC value of 4095 and the corresponding ET227 current. Working backwards, that will be 3.1 A and should suffice for all but the highest peaks at high line voltage.

2014-12-26
Kenmore 158: Recalibrated Hall Effect Sensor Amp

Reducing the differential amp gain fits a higher current into the Arduino’s fixed 5 V ADC range:

Hall Sensor Differential Amp

Those are 1% resistors, chosen from the heap for being pretty close to what I needed. Given that it’s an LM324 op amp, we’re not talking instrumentation grade results here.

The same calibration run that produced the DAC plot gave these values:

Current Calibrate – ADC – 270k Hall 2.7k opto

The linear fit gives the actual current, as seen by the Tek probe, for a given ADC reading.

The trimpot controls the offset voltage at zero current; working backwards, ADC = 0 corresponds to 140 mV, a bit higher than the actual 90 mV. Close enough, at least for a linear fit to eyeballed data, sez I.

Working forward, the maximum ADC value of 1023 corresponds to 4 A, which should suffice.

2014-12-24
Kenmore 158: Motor Flyback Diode

Although small power diodes make fine flyback diodes for relays, the motor can draw several amps during the startup pulse, which will be a bit out of spec for the usual 1N4007-class diodes. Pressing an old 5 A / 200 V stud diode into service produces the ungainly black-and-blue lump eating the end of the green wire:

Motor flyback diode – installed

For completeness, here’s the entire AC line interface part of the schematic:

AC Power Interface

The diode’s 200 V limit should suffice, even for cold starts at high line peaks, but, when you build this with new parts, get something rated a bit higher, OK?

The four NTC power thermistors lie just to the right of the relay, before the bridge rectifier.

2014-12-23
Kenmore 158: Pulse Drive
A Circuit Cellar reader sent me a lengthy note describing his approach to slow-motion AC motor drives, designed for an already ancient truck mounted radar antenna back in 1972-ish, that prompted me to try it his way.

The general idea is to pulse the motor at full current for half a power line cycle with an SCR (rather than a triac) at a variable pulse repetition rate: the high current pulse ensures that the motor will start turning and the variable repetition frequency determines the average speed. As he puts it, the motor will give off a distinct tick at very low speeds and the maximum speed will depend on how the motor reacts to half-wave drive.

Note that this is not the chopped-current approach to speed control: the SCR always begins conducting at the first positive-going 0 V crossing after the command and continues until the motor current drops to zero. There are no sharp edges generating high-pitched acoustic noise and EMI: silence is golden.

The existing speed control circuitry limits the peak current and assumes that the motor trundles along more-or-less steadily. That won’t be the case when it’s coasting between discontinuous current pulses.

When I first looked at running the motor on DC, these measurements showed the expected relationship:

Kenmore Model 158 AC Motor on DC – Loaded and Unloaded RPM vs Voltage

Later on, plotting RPM against current (50 mA/step starting at 550 mA):

Motor RPM vs Current Steps – Accelerating

Eyeballometrically, the slowest useful speed will be 2 stitch/s = 120 shaft RPM = 1300 motor RPM. At that speed, under minimal load, the motor runs on about 20 V and draws 550 mA. At that current, the 40 Ω winding drops 22 V, which we’ll define as “about 20 V” for this discussion, so the back EMF amounts to pretty nearly zilch.

That’s what you’d expect for the fraction of a second while the motor comes up to full speed, but in this case it never reaches full speed, so the motor current during the pulses will be limited only by the winding resistance. At the 200 V peak I’ve been using for the high-line condition, that’s about 5 A peak, although I’d expect 4 A to be more typical.

So, in order to make this work:
- the optocoupler driving the base needs more current
- the differential amp from the Hall effect sensor needs less gain
Given the ease with which I’ve pushed the hulking ET227 transistor out of its SOA, the motor definitely needs a flyback diode to direct the winding current away from the collector as the transistor shut off at the end of the pulse. Because it’s running from full-wave rectified AC, the winding current never drops to zero: there will definitely be enough current to wreck the transistor.

The firmware needs reworking to produce discrete pulses at a regular pace, rather than slowly adjusting the current over time, but that’s a simple matter of software…
2014-12-22
Eyeglass Temple Re-Repair

Unfortunately, the smooth interior of the temple spring pocket and the smooth exterior of the hinge plate didn’t provide enough mechanical lock for the epoxy; the pieces pulled apart after a week.

So I put a stake in its heart:

Eyeglass temple – tapered pin

That’s a tapered brass pin from the Box o’ Clock Parts, buttered up with a dab of epoxy, then shoved firmly into a 41 mil (#59) hole drilled through the pocket and the edge of the hinge plate.

Fast-forward overnight, apply a Dremel grinding bit, and it looks passable:

Eyeglass temple – ground tapered pin

If that doesn’t hold, those glasses are gone.

2014-12-19
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.
2014-12-18