Archive for October, 2012
I would Just Say No:
smoke rubbery worm & twitch
After that rebuild, the first five recharges went like this: 21, 21, 21, 23, and 20 days. The last interval included seven days of vacation, during which the battery suffered just the usual self-discharge common to NiMH cells.
That’s about what the OEM battery delivered, back when it was new, so the new 600 mA·h cells seem to be about the right capacity. Obviously, the end of the OEM battery wasn’t nearly so pretty.
In round numbers, the wireless charger requires one hour to restore the energy drawn by one two-minute brushing: the thing charges for about 21 hours. There’s additional loss from three weeks of self-discharge in there: if 7 days of non-use = 1 brushing, then the usual 21 days = 3 brushings -> 14% loss due to self-discharge.
I’d take a large grain of salt with those numbers…
I’ve been doing some amateur surveying in preparation for the long-awaited driveway paving project, just to see where the property boundaries might be, and this Bosch GLR225 laser rangefinder makes it wonderfully easy to measure distances:
It’s good up to 230 feet = 70 meters, which means you can measure a sizable chunk of property in one shot. It reads down to 2 inches with 1/16 inch accuracy / resolution (call it 50 mm and 1.5 mm), so one could use it for setups in the shop. It can solve right triangles, which means you can measure distances with an obstruction in the middle, and has a few other tricks. Other rangefinders evidently have more tricks, but I favor writing direct measurements on paper and making computations based those values, rather than using mysterious results direct from the field that can’t be easily verified at the desk.
I tried measuring the nominal 212 foot distance to the Hudson River from the center of the Walkway, but it reported an error. Most likely, specular reflections from water don’t work well, at least not at that distance.
You can buy retroreflective targets, but the Basement Laboratory Warehouse Wing disgorged what looks like roadside border markers, pre-bent into a useful shape:
Seen by reflected light, they’re much more impressive:
They came with the house, so I don’t know their provenance. What I do know is that I can’t hold the rangefinder steady enough to keep the spot on the target at much more than 100 feet. If I get around to doing much more surveying, I must conjure up a tripod mount; the base has a 1/4-20 socket in an awkward location and can measure relative to the screw centerline. Perhaps a rifle stock with a spotting scope would be handy, too, although I’d certainly acquire another black spot on my record.
If you were going to use it in the shop, you’d want a rotating pivot aligned at the intersection of the tripod socket and sensor port to get a known center point.
You can get one on eBay at a substantial discount, of course…
Back in December 2007 I printed four copies of a picture on various papers with the Canon S630 and hung them on a floor joist over my workbench, directly below a fluorescent shop light. Having just hung those screwdrivers where the pictures used to be, it’s time to see what’s happened.
The pictures, scanned on an HP C7670A (aka Scanjet 6300C) against the neutral gray of the ADF platen:
The papers, clockwise from lower left:
While the scanner isn’t renown for its color fidelity, the overall results look about right; the platen really is that shade of gray and the upper-right picture has a sickly green hue.
The faded edges along the right side of the left-hand image show where the adjacent sheet overlapped: the colors didn’t fade nearly as much. The small rectangles on the lower left corners of the right-hand images show where I put clothes pins to keep the sheets from curling.
All of the images have a blue overtone; the magenta dye fades out with exposure to UV from the fluorescent fixture.
As you’d expect, the glossy paper looks best, with very crisp detail. The inkjet paper is next, followed by the matte, and the plain paper in the upper right obviously doesn’t support the ink well at all.
Of course, after five years I no longer have any of those papers and am using entirely different ink…
To show that the scanner really does matter, here’s the same set of images from a Canon LiDE 30:
In both cases. that’s without any color correction / gamma compensation / whatever. I should fish out my scanner calibration targets and go through the whole color calibration dance again; with any luck, the Linux color management infrastructure will be less inadequate by now.
Memo to Self: If you love it, don’t expose it to UV.
We always wish “our” hawks, whatever and wherever they may be, good hunting…
This came from the first set of real pictures using the repaired Sony DSC-H5 zoomed to 12× with the 1.7× tele conversion lens, cropped down a bit: plenty of artifacts to choose from.
Our Larval Engineer may have a commission to fit her Speed-Sensing Ground Effect Lighting controller to another longboard. To that end, the case now sports mouse ears to spread the force from the cooling ABS over more of the Kapton tape, in the hope the plastic won’t pull the tape off the aluminum build platform:
That view shows the bottom slice that will hold the battery, but the ears appear on all three layers.
The OpenSCAD source code is now up on Github, which should make it easier to update & share.
For quite some time, the Canon S630 printer connected to the file server downstairs has been printing some documents in what looks like garbled reverse video: all of the text areas render as white characters on a black background, with peculiar graphic gibberish filling the space to the right margin. I’d provide a picture, but it wouldn’t be too informative; suffice it to say that if I wasn’t using bulk ink the pages would cost about a buck each.
Printing documents with two-up pages (two document pages on one paper sheet) generally resulted in the first sheet coming out garbled with the remainder emerging unscathed, but sometimes I found an entire stack of black paper. Ouch!
This usually affected documents printed from Web pages, but sometimes clobbered pure PDF documents. Given that Linux printing involves multiple transformations between Postscript / Ghostscript / PDF / PNG / what-have-you, it’s impossible to pin down a common cause.
Searching for the obvious keywords showed other folks had similar problems with different printers and different drivers. None of the threads had any resolution.
Printing the same document on the Epson R380 worked perfectly.
One recent morning I had four out of six documents fail, so I tried some of this and a little of that, before it occurred to me that I should switch the driver. I had chosen the default recommended printer driver during installation: the oddly named bj8xxyyz.upp file produced by the Ghostscript folks. Switching to the Gutenprint 5.2.7 driver seems to have solved the problem; all four failing documents printed perfectly and the problem hasn’t returned in a week of printing.
The R380 was already using the Gutenprint driver, which (in retrospect) should have been a big, fat hint.
I’d file a bug report, but to which project about what? [sigh]