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: Science

If you measure something often enough, it becomes science

Strobe Photography: Drop Tests vs. Xenon Flash Energy
Tweaking the Arduino program to fire the LED 10 ms after the beam breaks, then fire the Xenon strobe 180 ms later produces this result:

Drop test – ISO 800 – 100 ms f8 – overexposure

Obviously, that’s far too much light: ISO 800, 1/10 sec, f/8, with the flash a few inches from the action. There aren’t many free variables:
- Shutter must be open long enough to span the timing jitter
- Aperture is already as small as it gets for good depth of focus
- ISO speed may be too high
- Flash intensity is fixed for a given capacitor
Throwing a shop rag over the flash helps a bit, capturing the ruler suspended in mid-air:

Drop test – ISO 800 – 100 ms f8 – cloth

However, replacing the 250 µF electrolytic flash capacitor with a 1 µF film cap reduces the stored energy by roughly an order of magnitude and reduces the flash pulse duration to about 100 µs.

The bottom two inches of the ruler now have lighting from the flash, while the rest of the image looks pretty good in natural light:

Drop test – ISO 800 – 100 ms f8 – 1 uF

It turns out that having the laser and photodiode beam-break sensor within the view (the white ring at the top) doesn’t work, as the CHDK motion detector will notice the red spot on the ruler and trigger the shutter before the LED (clipped to the right of the vertical steel scale) flashes.

Several more trials showed that the flash fires consistently, but (as expected) the shutter triggering has some jitter. In this case, the shutter remained open after the flash and captured a blurred image as the ruler continued to fall:

Drop test – ISO 800 – 100 ms f8 – tail

Here, the shutter closed immediately after the flash, eliminating the blurred tail:

Drop test – ISO 800 – 100 ms f8 – no tail

Having the shutter close before the object reaches the bottom of the image is a Bad Thing, as it means the shutter triggered too early.

In both cases, the sharp image of the ruler overlays the blurred image captured in natural light. That’s more visible toward the top of the picture where the flash doesn’t reach very well.

I aligned the laser beam-break detector at 200 mm on the scale and the flash fired when the tip of the ruler was at 390 mm = 190 mm below the beam. The LED blinked 10 ms after the beam break and the Xenon flash fired at 180 ms; given all the vagaries involved, 190 mm is just about spot on the (revised) estimates.

But that background has got to go…
2014-03-26
Canon SX230HS vs. CHDK: Motion-Detection Shutter Delay
Given those results showing that I had badly misjudged the delay from the time the CHDK motion-detection script notices a change until the time the shutter opens, some tests were obviously in order. I covered a door with black cloth, pinned a yardstick with metric divisions (it’s actually 4 ft long) to the cloth, set up the camera a meter away, zoomed in on the stick, fired up CHDK, and dropped a squishy foam star…

A composite image from three trials at 1/100 sec, ISO 800, manual everything, and the star starting with its bottom at the top of the stick:

SX230HS CHDK MD delay – 10 ms shutter

There’s no way to know exactly when the CHDK script detected the falling object, but I think it’s reasonable to assume the star was about halfway visible: call it a 50 mm drop that takes 100 ms.

In the left image, the bottom reaches 140 mm at 170 ms, which says the shutter delay is about 70 ms.

In the right image, the bottom is at 380 mm at 280 ms, so the delay is a whopping 180 ms.

The majority of the images, at all shutter speeds, seem to trigger with the bottom of the star around 250 mm at 225 ms, for a shutter delay of 125 ms. Based on a bunch of other pictures, a reasonable guesstimate would be a shutter delay of 125 -30 +30 ms, which says the shutter must be open for about 60 ms = 1/17 s; the camera can do 1/25, 1/20, 1/15, 1/13, and 1/10 in that range, so 1/15 s = 67 ms sounds about right.

Here’s a hand-picked assortment of shutter speeds, chosen for about the same vertical position when the shutter opens, showing that the motion blur scales exactly the way you’d expect:

SX230HS CHDK MD – shutter variations

Those are 1/100, 1/50, 1/25 and 1/13 s, respectively, all at ISO 800 with the iris wide open at f/4. You can see the increasing exposure from left to right.

In order to catch an object at 200 mm below the trigger point, the LED must flash almost immediately after the object breaks the laser beam in the sensor. Assuming the drop starts just above the beam, the timings for 1/15 s = 67 ms work out to (in round numbers):
- Minimum: open @ 100 ms = 50 mm, remain open until 170 ms = 140 mm
- Maximum: open @ 160 ms = 120 mm, remain open until 230 ms = 250 mm
That says the Xenon strobe must happen 165 ms after the beam breaks, with ±5 ms tolerance on either side, and the object will be 130 mm below the sensor.

The minimum shutter time might be 1/10 s = 100 ms, just to build up some slack:
- Minimum: open @ 100 ms = 50 mm, remain open until 200 ms = 200 mm
- Maximum: open @ 160 ms = 120 mm, remain open until 260 ms = 330 mm
That way, the strobe can happen anywhere between 160 and 200 ms, with some assurance of catching the object between 120 and 200 mm below the beam.

Adjusting those delays is a simple matter of software, but ya gotta know where to start…
2014-03-25
Strobe Photography: Time Estimates and First Light

The object being to light up a falling object at a known position, I ran off the usual Physics 1 spreadsheet relating position, time, and speed for the ideal case:

Initial Timing Estimates

I wanted the flash to occur when the object was about 200 mm below the trigger point (the laser-photodiode beam-break sensor), which turns out to be, conveniently enough, 200 ms after the drop. A 1/25 = 40 ms shutter time allowed for the ±10 ms or so of jitter that I assumed would be due to the CHDK motion-detection script, but I did not have a good estimate of the delay from motion detection to shutter opening; I assumed it would be nearly zero. That meant the LED flash must occur about 50 ms earlier, at about 150 ms from the drop and 60 ms from the beam break; assuming I dropped the object about 30 mm above the beam break sensor.

Soooo, I baked those numbers into an Arduino program (more on that later), lashed the hardware together, and fired it up.

The beam-break sensor worked, the Arduino code worked, the LED and Xenon strobe fired, but all the pictures were black: the LED triggered the motion detection script, but the flash occurred either before or after the shutter opened.

After considerable adjustment of times, twisting of knobs, and general flailing around, this happened:

Strobe flash – falling ruler – top

If you look very, very closely, you can see a thin rectangular object at the top edge of the picture, just to the left of the machinist’s scale supporting the beam-break sensor, which, in turn, is barely visible to the left of the mysterious rectangle.

The round eye-like object peering at you from 1/3 up the scale is the 10 mm white LED that triggered the motion-detection script. It’s dark, because that flash ended long before the shutter opened.

More flailing around stopped the object in the middle of the image:

Strobe flash – falling ruler – middle

The motivation for dropping a ruler: it’s long enough that you’re bound to catch at least part of it and the graduations let you estimate distances and times fairly accurately. That’s after you manage to catch at least part of it, of course.

Increasing the flash delay caught it just before it hit the white towel causing the retina-burn glare at the bottom:

Strobe flash – falling ruler – bottom

A bit of detail from another picture with the ruler near the middle shows that the 1 ms Xenon strobe flash really does stop the action:

Strobe flash – falling ruler – detail

Even though the initial timing estimates were completely wrong, there’s some hope this will actually work…

2014-03-24
Red Laser vs. IR LED Photosensor

As Forrest Mims demonstrated back in the day, LEDs work perfectly well as narrow-band photodiodes with peak sensitivity to slightly shorter wavelengths than they emit. Aiming a red laser at an ordinary IR LED about a foot away generates 800 mV of photovoltage:

Red laser – IR LED detector

The blip comes from the shaft of a small screwdriver falling through the beam.

That’s in photovoltaic mode directly connected to the oscilloscope, but you’d want to run it through a low-gain transimpedance amplifier to get the zero bias photocurrent and a comparator for a clean digital edge. That’s obviously overkill for a simple optical interrupter, but the analog circuitry should come in handy for something else later on.

OK, now I can detect a moving object, trigger a camera, and fire a xenon flash, all under an Arduino’s control…

2014-03-19
Monthly Image: Male Mammogram

This is not the Monthly Image I had scheduled for today…

A few weeks ago I reported to my doctor that I had a pressure-sensitive lump in my right breast. This happened the very next day:

Left-right Mammogram

It’s a composite of two mammogram images, of my left and right breasts, respectively, with the small white dots marking the obvious targets and the ring above the right dot surrounding a mole. You will be unsurprised to know that the radio-opaque markers came on cheery flowered stickers:

Radio-opaque targets

According to the American Cancer Society, about 2400 men will receive a diagnosis of breast cancer in 2014 and 430 men will die; those guys vanish in the roundoff of women’s breast cancer.

Given such small numbers, what you see up there on the right is almost certainly an unusually tender and mostly unilateral case of gynecomastia, which was the diagnosis relayed from the radiologist after the imaging. Because things are different for guys, there’s an appointment with an oncologist (yes, she specializes in breast cancer) and, perhaps, some biopsy samples in my immediate future.

They triage the appointment schedule based on radiographic evidence. Fortunately, I’m not on the hot list.

Potential oversharing ahead …

Some browsing with the obvious keywords shows that side effects of the blood pressure dope I was taking last year probably triggered my symptoms, with calcium channel blockers and spironolactone the most directly implicated drugs. It turns out that my blood pressure seems OK without drugs (now that they moved the goal posts for my age bracket, anyway), but we devoted half a year to discovering that nothing produced much of a direct effect and the side effects were completely unacceptable.

Protip: it’s probably not worth reducing a male’s androgen levels just to see if his blood pressure goes down. [sigh]

Back to the usual tech stuff …

Returning home with a CD of digital images in hand, I found that, unlike those older X-ray images, feeding these DICOM images (all sporting informative names like IN000001) into the current version of Imagemagick‘s convert triggers a segfault. Rummaging in the repositories produced a dedicated conversion program:

medcon -f IN* -c png

… which grinds away on the DICOM files and spits out PNG image files with the same names prefixed with an ascending sequence number of the form m000-. A burst of Perl regex line noise removes the prefixes:

rename 's/m[\d]{3}-//' *png

Figuring that out neatly diverted my mind from the Main Topic for a while…

Let this be an example to him who would be admonished: ask the Lady of your life for a preliminary checkup. She’ll know how to recognize what you didn’t think to check.

[Update:

The oncologist says I have a classic, textbook case of gynecomastia; if her med students weren’t on break, she’d use me as an example.

About 10% of males taking spironolactone for blood pressure control develop gynecomastia, typically in only one breast. Absent any other signs, there’s no need for biopsy samples or surgical intervention. The symptoms generally resolve within a year after discontinuing spironolactone.

Should the symptoms persist and become objectionable, treatments include surgery or tamoxifen… but I’m not down with that.]

2014-03-15
Makergear M2 Z-axis Backlash Numbers

Clamping a long-stroke dial indicator to the M2’s X axis gantry:

Dial indicator – gantry to M2 Y rail

Then stuffing manual G-Code into Pronterface produced some data on Z-axis accuracy, repeatability, and hysteresis:

M2 Z-axis positioning measurements

Note that the commanded positions are in 0.001 mm units (25 = 0.025 mm) and the observed positions are in mils (1 = 0.001 inch). The arrows indicate which way the stage moved, with positive Z increments moving the stage down.

I summarized this as part of a discussion on the Makergear Google Group…

The overall distance seems to be quantized at 0.0150 mm = 6 step intervals. You can command a motion between those steps (G0 Z0.0025, G0 Z0.0075, etc), but the motor doesn’t turn until the distance exceeds the next interval (G0 Z0.0150 causes motion). This isn’t stiction, because the firmware isn’t activating the motor.

Stepping up and down in 0.025 mm increments (10 steps, but not an even multiple of the 6 step quantization intervals) over a 0.100 mm range produces about 0.01 mm = 4 steps of backlash. Some of that definitely comes from the quantization interval, but it’s not consistent, so there’s also mechanical backlash.

Frankly, that’s better than I expected, but any motion less than about 4 steps probably won’t happen and the errors are on the same order. Whether the firmware itself can compute and apply a smaller motion isn’t clear.

The controller doesn’t know where the platform is, at least in an open-loop stepper system. That means when the commanded motion is on the same order as the backlash, the controller can’t make the proper adjustments. As long as the positioning error remains smaller than the tolerance, it’s all good; expecting 0.020 mm resolution and accuracy seems reasonable.

But it’s only a quick-and-dirty test, so I wouldn’t read too much into it.

2014-03-06
Monthly Science: Town Water Inlet Temperature
Back in 2006, I clamped a Hobo temperature sensor onto the pipe that delivers town water from the main, under 150 feet of front yard, and into our basement:

Town Water Inlet – temperature sensor mounting

Wrapping a chunk of closed-cell foam insulation around it made me feel better, but probably doesn’t affect the results very much at all:

Town Water Inlet – temperature sensor insulation

I assume the temperature of the pipe at that location will match the water temperature pretty closely, at least while some water flows into the house, and the water temperature will match the ground temperature four feet under the front yard.

Under those assumptions, the bottom trace shows the pipe temperature and the top trace shows the air temperature on the shelf a few feet above the pipe:

Town Water Inlet

The gap in early 2011 documents an embarrassing bit of forgetfulness. All in all, you’re looking at about 750,000 logged records; if you observe something long enough, it turns into science.

Cleaning up the date and time columns in the data files required a few hours of heads-down sed experimentation:
- Convert quoted headers to comments → s/^\"/#&/
- Convert non-data records to comments → s/^.*Logged/#&/
- Convert two-digit years to four-digit years and enforce trailing blank → s_/\([01][0-9]\)[ ,]_/20\1 _
- Enforce blank after four-digit years → s_/\(20[0-9]\{2\}\),_/\1 _
- Remove blank after time-of-day value → s_\(:[0-9]\{2\}\) _\1_
Being reminded that sed will accept (nearly) any delimiter character came in handy!

The temperature spikes happen when I bring the Hobo datalogger upstairs to read it out. The plotting routine discards the junk readings caused by unplugging the remote sensor; anything below 30 °F or above 100 °F counts as spurious. The gnuplot idiom uses the ternary operator with the Not-a-Number value:
```
plot "filename" using 2:((\$3 > 30) && (\$3 < 100) ? \$3 : NaN) with ...</code>
```
The backslashes escape gnuplot’s variable markers, which would otherwise get eaten by Bash.

The Bash / gnuplot script that produces the plot:
```
#!/bin/sh
#-- overhead
export GDFONTPATH="/usr/share/fonts/truetype/"
base="${1%.*}"
echo Base name: ${base}
tfile1=$(tempfile)
ofile=${base}.png
echo Input file: $1
echo Temporary files: ${tfile1}
echo Output file: ${ofile}
#-- prepare csv Hobo logger file
sed 's/^\"/#&/ ; s/^.*Logged/#&/ ; s_/\([01][0-9]\)[ ,]_/20\1 _ ; s_/\(20[0-9]\{2\}\),_/\1 _ ; s_\(:[0-9]\{2\}\) _\1_' "$1" > ${tfile1}
#-- do it
gnuplot << EOF
set term png font "arialbd.ttf" 18 size 950,600
set output "${ofile}"
set title "${base}"
set key noautotitles
unset mouse
set grid xtics ytics
set timefmt "%m/%d/%Y %H:%M:%S"
set xdata time
#set xlabel "Week of Year"
set format x "%Y"
set ylabel "Temperature - F"
set yrange [30:90]
set datafile separator ","
plot	\
    "${tfile1}" using 2:((\$3 > 30) && (\$3 < 100) ? \$3 : NaN) with lines lt 3 title "Air", \
    "${tfile1}" using 2:((\$5 > 30) && (\$5 < 100) ? \$5 : NaN) with lines lt 4 title "Water"
EOF
```
2014-03-01