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: Photography & Images

Taking & making images.

  • 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
    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
    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
    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
    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
    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…

  • 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
    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
    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…

  • 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
    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
    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
    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
    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
    Strobe flash – falling ruler – detail

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

  • Squirrel Eating Ice (-sicle?)

    This being the time of year when the sap flows, we think one squirrel enjoyed a sweet treat:

    Squirrel with ice - 1
    Squirrel with ice – 1

    He nibbled the ice for several minutes:

    Squirrel with ice - 2
    Squirrel with ice – 2

    … until finally bounding away with the remnant in his teeth. Brrr!

    Taken with the DSC-H5 and tele-adapter braced against the back door frame, zoomed in all the way.

  • Strobe Photography: Circuit Doodles

    The general idea:

    There’s nothing too complicated about any of that.  I used 2N2907A PNP transistors because I’m running out of those cute little ZVNL110A logic-level MOSFETs; remember that you can’t hitch the emitter to anything higher than +5 V, unless you want to toast the Arduino. Using a PNP switch means that the initial state of the Arduino pins won’t inadvertently turn the LED / laser / flash on.

    The laser-photodiode detector:

    Laser-photodiode detector - schematic
    Laser-photodiode detector – schematic

    The 20 MΩ resistor sets the gain at 20 mV/nA, which is both absurdly high and seems to work. The IR LED serving as the photodiode doesn’t pass much photocurrent, particularly with the laser running just above threshold, but the fact that it’s totally unresponsive to room light helps a lot; there’s something to be said for a narrow spectral response, which a real photodiode doesn’t have. I do have some IR photodiodes in tinted packages and might be forced to do some rummaging.

    I expected to need a comparator after the transconductance amplifier, but with that much gain the LM324 has a nice, steep edge when the object goes past. The laser beam is small enough that there’s not much error due to convolving the object’s edge with the beam; it’s basically binary.

    With the LM324 quad op amp running from +5 V, its output can’t get above +4 V. That’s good enough for a logic-level trigger, although a real circuit should use something like the MAX4330 I hacked into a DIP footprint.

    The white LED driver uses a 10 mm package with five white LED chips in parallel that runs at 100 mA:

    White LED driver - schematic
    White LED driver – schematic

    I found an LED lashup that I’d built to light up a bird box, so the resistor (which is 12 Ω, not the 100 Ω due to a finger fumble) actually lives at the LED on the other end of the cable, inside a heatshrink strain relief.

    The Xenon photoflash driver uses a small relay hacked into the trigger circuit, with a Schottky diode to recirculate the winding current when the transistor turns off:

    Xenon flash relay driver - schematic
    Xenon flash relay driver – schematic

    The diode increases the relay release time, which doesn’t matter here.

    The delays from the laser beam break to the flashes should be variable, so there should be a knob with a pushbutton: turn to set the Xenon flash delay, push-and-turn to set the LED flash delay. I doubt that this calls for a digital display, as you can see whether the flash happens at the right time…

  • Digitally Triggered Camera: Canon SX230HS

    The CHDK firmware for Canon point-and-shoot cameras includes a USB remote trigger feature that depends on simply applying +5 V to the USB power leads, which is exactly what happens when you plug an ordinary USB cable into a PC.

    Chopping up a spare cable, adding header pins, attaching a bench supply, and whacking the pins with clip leads showed that the camera takes quite a while to haul itself to its feet and click the shutter:

    Canon SX230HS - USB trigger - flash
    Canon SX230HS – USB trigger – flash

    That’s with:

    • Manual mode: preset shutter & aperture
    • Manual focus
    • Focus assist off
    • Image stabilization off
    • AF guide light off
    • Red eye reduction off
    • Flash enabled, medium intensity, precharged

    Turning the flash off slightly reduces the delay, at least judging from when I hear the shutter click while watching the trace trundle across the screen. I may have forgotten to turn something else off, but I doubt it’ll get an order of magnitude faster.

    I’d hoped to synchronize an outboard flash with the shutter, but watching a few traces shows that the time from trigger to flash isn’t very consistent; maybe 100 ms jitter, more or less.

    The CHDK motion-sensing script works and is “lightning fast”, but it turns out that lightning strokes actually glow for tens to hundreds of milliseconds, so my 1 ms xenon flash will be over and done with by the time the script reacts and opens the camera shutter.

    Other ways to synchronize an outboard flash with the shutter:

    1. Fire the outboard flash from the camera flash, with the camera flash inside a shield
    2. Use an absurdly long shutter time with the camera & objects inside a very, very dark enclosure
    3. Use the CHDK motion detection script, but blink an LED into the lens to trigger the shutter, then fire the xenon flash to expose the image

    Choice 1 has positive synchronization to the camera shutter, but the shutter delay jitter means the flash won’t happen after a fixed delay from the triggering event. Maybe it’s not as bad as I think.

    Choice 2 requires that the shutter stay open longer than the maximum delay jitter, so the flash will happen at known time after the triggering event. I like that, but not the dark enclosure part.

    Choice 3 depends on the timing jitter of the script, which should be on the order of a few tens of milliseconds. A shutter speed of 1/25 s = 40 ms might be Good Enough.

    This obviously requires a bit of Arduino fiddling…

  • Digitally Triggered Xenon Flash

    I’m thinking of taking strobe pictures again, but the results of the LED strobe tach experiment showed that I need many more LEDs, much brighter LEDs, or entirely different technology. The Big Box o’ Xenon Tubes disgorged some surplus camera flash units that seemed amenable to hackage.

    The canonical digital trigger uses an optocoupled triac, so I soldered a MOC3022, taken from a random assortment of various optocouplers, across the trigger leads:

    Xenon flash - MOC3022 triac
    Xenon flash – MOC3022 triac

    Alas, that didn’t trigger the flash reliably. It may well be that the triac’s leakage current drains the small trigger capacitor below the voltage required to produce a suitable trigger pulse, but I was unwilling to poke around in the thing.

    The clip leads go off to a DVM set to the 600 VDC range, which is, I think, the first time the range switch has ever lingered in that position. The 250 µF 330 V capacitor charges to about 300 V, depending on the mojo of the single AA cell powering it, and discharges to about 50 V after the arc quenches. The neon bulb lights when the capacitor goes above 280 V.

    The reed relay assortment emitted an ancient Clare 1A05C relay with, as nearly as I could make out from the fragmentary datasheets available nowadays, barely adequate specs:

    Xenon flash - PRME 1A05C relay
    Xenon flash – PRME 1A05C relay

    Unfortunately (and as I rather expected), the first shot welded the contacts together.

    A somewhat larger Axicom (aka Tyco) V23079A1011B301 (I’m not making that up) relay had better specs: 220 VDC / 250 VAC / 2 A contacts. The DC rating isn’t relevant here, because the contacts will break only 50 V after the flash, and the AC rating says it’ll withstand well over 350 V.

    As with the other gadgets, a blob of hot melt glue holds it in place:

    Xenon flash - Axicom V23079 A1011-B301 relay
    Xenon flash – Axicom V23079 A1011-B301 relay

    That worked wonderfully well:

    Xenon 280 V 250 uF
    Xenon 280 V 250 uF

    The upper trace comes from a PIN-10AP photodiode in the LED measurement fixture, minus the black cap holding the LED. The photodiode connects directly to the oscilloscope input, so we’re seeing its photovoltaic response rather than the photocurrent, but that’s good enough for now. The pulse is about 1.5 ms long at the 50% level (that’s 1 EV down from the peak) and the tail is pretty much gone by 3 ms.

    The 3 ms delay after applying voltage to the coil (lower trace, showing what happens when you use a clip lead as a switch) is well within the 4 ms spec in the datasheet. The release time isn’t relevant, as the capacitor has discharged to 50 V and nothing exciting happens when the contacts open.

    Charging the stock 250 µF cap to 280 V stores 10 J = 10 W·s:

    10 J = (1/2) (250×10-6) (2802)

    Discharged to 50 V, the cap has only 0.3 J left, so most of the energy goes into the arc.

    Swapping a 1 µF 600 V film capacitor for the electrolytic cap narrows the pulse:

    Xenon 350 V 1 uF
    Xenon 350 V 1 uF

    A 1 µF cap should reduce the stored energy by a factor of 250 to 0.4 J, but the booster charged it to 350 V = 0.6 J:

    0.6 J = (1/2) (1×10-6) (3502)

    The test setup, a term that barely applies in this situation, isn’t stable enough to say anything about the relative light output, but it’s certainly not an order of magnitude worse than the 10 J shot (some data and curves from an OEM). The pulse width is maybe 100 µs, just about what I used with the LEDs, but whether the lamp produces enough illumination remains to be seen; it should be brighter than the LEDs.

    The boost circuit requires about ten seconds to recharge the 250 µF cap and maybe 250 ms for the 1 µF cap. The Axicom relay can operate at 50 Hz at no load, which definitely won’t constrain the flash rate. The trigger energy at the contacts should be about the same for either flash capacitor, because it comes from a much smaller capacitor charged to the same voltage; buzzing away at a high rep rate will chew up the contacts fairly quickly.