Author: Ed

Repurposing Tomato Cages

Bending tomato cage wires

Mary wanted to convert some old tomato cages into flower supports and deer protectors (until the flowers get big enough), by the simple expedient of flipping the cages over with the large end down. She figured we could chop off the wire ends that normally anchor the cages to the ground, then bend them into hooks for secure ground anchors.

I deployed the linesman’s pliers, which only showed that my wire size estimation is grossly underdeveloped. The high-carbon steel wires required bolt cutters… but a few minutes of twang effort scattered two dozen really stiff wires across the patio.

I ran a marker across the pile at the bend point, grabbed two random steel rods in the vise and, in short order, bent up a stack of ground anchors.

Not every job requires G-Code …

2010-07-02
Kensington Expert Mouse Trackball vs X Server 1.8
After the fuffing and fawing required to get the Wacom tablet up to speed, swapping the buttons on the Kensington trackball required just one stanza in /etc/X11/xorg.conf.

To wit:
```
Section "InputClass"
Identifier      "Kensington Trackball"
MatchProduct    "Kensington Expert Mouse"
Option          "SendCoreEvents" "True"
Option          "ButtonMapping" "3 8 1 4 5 6 7 2"
EndSection
```
For some no-doubt logical reason, it Just Works without an InputDevice stanza or anything in ServerLayout.

That will swap the buttons on any matching trackball, should I be so bold as to plug more than one in at a time …

The old FDI file is there.
2010-07-01
Monthly Aphorism: On Being Square
- If you can’t be smart, be square
Father Vaughn spent many years in IBM’s semiconductor biz, where he realized that the proper shape for a silicon chip was not long and skinny.

His engineers would argue that they could lay out the logic much more easily on a rectangle. While that was true, he knew something they didn’t: high aspect ratio shapes snap much more easily during processing. An optimum layout doesn’t matter when you can’t build the chips.

His aphorism also applies to human behavior: you’re rarely as smart as you think you are. Being square, in the stodgy, conventional, risk-averse sense, may save your bacon.
2010-06-30

Wacom Graphire3 vs X Server 1.8

A recent Arch Linux update introduced Version 1.8.1 of the X server, which jettisons the whole HAL infrastructure in favor of udev. This is almost certainly a step in the right direction, but once again it’s time to figure out exactly how to get my Wacom Graphire3 tablet running.

The solution turns out to be putting all the configuration options back in /etc/X11/xorg.conf, exactly where they started out before they moved into HAL FDI files. Not that any of this is obvious, mind you, but that’s how it works out.

So.

At this point, the Arch Linux linuxwacom-bamboo-cth-ctl package installs the only Wacom driver version (0.10.7-4) that works with X 1.8+.

In /etc/udev/rules.d/10-wacom.rules the two highlighted lines match the Graphire and throw the evdev driver overboard if it got control. The top line was the original file; I commented it out and inserted the rest based on a thread in the Arch wiki; I think the original would work fine.

###KERNEL=="event*", ID_VENDOR_ID=="056a", NAME="input/%k", SYMLINK="input/wacom"
# udev rules for wacom tablets.

KERNEL!="event[0-9]*", GOTO="wacom_end"

# Multiple interface support for stylus and touch devices.
DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="00", ENV{WACOM_TYPE}="stylus"
DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="01", ENV{WACOM_TYPE}="touch"

# Convenience links for the common case of a single tablet.  We could do just this:
#ATTRS{idVendor}=="056a", SYMLINK+="input/wacom-$env{WACOM_TYPE}"
# but for legacy reasons, we keep the input/wacom link as the generic stylus device.
ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}!="touch", SYMLINK+="input/wacom"
ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}=="touch", SYMLINK+="input/wacom-touch"

# Check and repossess the device if a module other than the wacom one
# is already bound to it.
ATTRS{idVendor}=="056a", ACTION=="add", RUN+="check_driver wacom $devpath $env{ID_BUS}"

LABEL="wacom_end"

When X wakes up, it stitches together a bazillion snippets of config options that used to live in /etc/X11/xorg.conf. This default snippet in /etc/X11/xorg.conf/50-wacom.conf seems to be OK, although only the highlighted stuff applies to my setup.

Section "InputClass"
	Identifier "Wacom class"
# WALTOP needs a patched kernel driver, that isn't in mainline lk yet,
# so for now just let it fall through and be picked up by evdev instead.
#	MatchProduct "Wacom|WALTOP|WACOM"
	MatchProduct "Wacom|WACOM"
	MatchDevicePath "/dev/input/event*"
	Driver "wacom"
EndSection

... snippage ...

Meanwhile, back in /etc/X11/xorg.conf, the tablet requires two InputDevice stanzas and their corresponding ServerLayout entries.

Section "ServerLayout"
    Identifier     "RotatedPortrait"
    Screen      0  "Landscape" 0 0
    Screen      1  "Portrait" RightOf "Landscape"
    InputDevice     "Wacom - stylus"
    InputDevice     "Wacom - eraser"
EndSection

Section "InputDevice"
    Identifier      "Wacom - stylus"
    Driver          "wacom"
    Option          "Device" "/dev/input/wacom"
    Option          "USB" "on"
    Option          "Type" "stylus"
    Option          "Button2" "3"
    Option          "Button3" "2"
    Option          "MMonitor" "off"
    Option          "ScreenNo" "0"
    Option          "BottomX" "16725"
    Option          "BottomY" "11893"
EndSection

Section "InputDevice"
    Identifier      "Wacom - eraser"
    Option          "Device" "/dev/input/wacom"
    Driver          "wacom"
    Option          "USB" "on"
    Option          "Type" "eraser"
    Option          "MMonitor" "off"
    Option          "ScreenNo" "0"
    Option          "BottomX" "16725"
    Option          "BottomY" "11893"
EndSection

I haven’t checked to see if the driver still requires the BottomX / BottomY values to keep the cursor from crashing X when it enters the crack between the displays.

Most of that is documented in the man pages for xorg.conf and wacom.

The corresponding FDI file for the previous X Server is there, just in case you want to compare notes.

2010-06-29

Zire 71 Button Protector

Zire 71 button protector

I carry around an ancient Zire 71, from the time before PDAs merged with phones and PCs to become fashionable objects of desire.

Anyway, it turns out that the buttons on the front are remarkably easy to squash in your pocket: the poor thing spends a lot of time turning itself on and off. I machined a plate with two holes for the four buttons and a lengthwise recess with two notches for the joystick selector. The whole affair slides into the pouch Mary made for it and works fine.

I tweaked the thing a bit when I got a replacement Zire a few months ago; the grippy tape I put on the sides seemed to be just large enough to force the joystick against the protector while sliding it into the pouch. Now that’s not a problem.

Zire 71 protector in place

This is in the nature of documentation, just in case I need something like this ever again. I found these pix while looking for something else …

2010-06-28
HT GPS + Audio: Case Dimensions

Having obtained eyeballometric measurements from the case, the next step was to doodle some shapes on graph paper and pencil in the dimensions. My motivation for not using CAD is simple: it’s easier (for me, at least) to doodle using a pencil.

The outside of the case had pretty much the same features.

Pack Layout – External

The inside, of course, bore no resemblance to the battery pack; the shoulder and whatnot will support the circuit board.

Pack Layout – Internal

The original battle plan was to build the case in at least two layers, simply because it had to be so deep the Sherline couldn’t reach to the bottom with any rational end mill. It would probably make more sense to glue up four sides on a machined bottom, but that requires actual skill.

This became the Front layer, with Front and Rear faces. The Rear layer attaches to the back of this one. In this picture, the Front layer is on the bottom, taped to the radio.

ICOM IC-Z1A with GPS+Audio Interface

The two layers peeled apart, with the Front layer to the right. You can barely see the internal shoulder and external tabs.

Interface – top and bottom surfaces

2010-06-27
ICOM IC-Z1A and W-32A: BP-171 Battery Pack Dimensions

Early on, I decided that the whole APRS + voice interface for our bikes had to fit on the back of the radio, which meant it had to look a lot like a BP-171 battery pack. The first step was to get all the relevant dimensions from an existing pack.

I laid a (rebuilt) pack on the scanner and took its picture. There’s a lip on the bottom (top in the image), so I held it level with the end of the calipers you can see near the bottom. That puts it slightly above the scanner’s focal plane, but it’s close enough.

Then I scanned some graph paper (remember that?) with 10 lines per inch, overlaid that on the pack image, rotated to line it up with the pack, scaled the grid so that the major lines were 1 cm apart on the pack in both directions, and that gave me a nice 1 mm grid to eyeball the measurements.

Printed the image out at about twice real size and there you have it:

Battery Pack Dimensions

The doodles around the bottom give the Z-axis dimensions for tabs & contact slots & suchlike.

The notes near the top were a first pass at how to mill the thing; two years later, the actual G-Code bears little resemblance to that.

I put the origin at the lower-left corner of the part that fits into the radio body, 2.4 mm inside the left edge that mates with the outside of the body. That was probably a mistake, as it meant I had to touch off the final part at X=-2.4 rather than just 0.0.

We live & learn.

2010-06-26