Close
0%
0%

Bullet Movies

Using red, green, and blue LEDs to capture short movies of very fast objects

Similar projects worth following
"Still" bullet photography has traditionally been done with an open camera shutter and fast gas-discharge flash lamps. Recently, LEDs have become bright enough to perform the same function. I'm taking this one step further and using red, green, and blue LEDs to capture three instants in time in a single camera image, which can be reconstructed into three separate frames with a little linear algebra. Although RGB exposures like this were done (on film, with flashlamps and colored filters) in the 1960s, modern technology brings this within reach of the average hacker.

Using 1 us flashes, this system will be capable of capturing images at 1 million frames/second - for 3 frames.

I wanted to call this project "Bullet Time for Real," but some jerks have a trademark on the phrase "bullet time."

The basic idea is to use a DSLR (and the fastest lens you can find/afford) in a darkened room with a long exposure (open shutter). As the projectile moves, three separate flashes of red, green, and blue light are produced, recording three separate instants in time on the red, green, and blue sensitive pixels of the camera sensor. In an ideal world, each sensor pixel would be sensitive to only a single LED color, producing three completely separate images. In reality, there is some cross-sensitivity: for instance, the green sensors see all three LEDs to some extent, causing ghosting from the other frames. I've developed a method for removing these ghosts, as explained in the first project log.

I'm approaching the development of this project in three phases. Each successive phase will work on timescales roughly 1000x faster than the last, introducing interesting new challenges.

Slow Timescale (Human)

I've already done some experiments on this scale - using low-powered LEDs and pulses of several seconds, I've been able to prove that the matrix-inversion ghost correction works. See details and images in the first log.

Medium Timescale (Milk Drop)

For these tests, I'm aiming to create some flashes of around 1 ms duration, fast enough to capture milk drops, popping balloons, and other medium-speed objects. In order to get enough light from the LEDs in these brief pulses, I'll need an array of LED chips driven with pulses tens of amps of current. I'll also need some way to trigger the flashes, and a variable time delay and flash sequencing mechanism to drive the LEDs. I'm planning to design some fast photodiode gates for triggering, and implement the timing functions on a PIC programmed in C and assembly.

Here are some initial results from the millisecond flash regime, shown as the original RGB image, a naively-separated animation, and after the ghost-reduction algorithm:

Fast Timescale (Bullet)

Three things are key to making this work: SAFETY, SAFETY, and SAFETY. Due to constraints of my space, I won't be using any firearms, only air rifles. Even so, these devices are capable of pushing pellets past the sound barrier, although I'll mostly concentrate on projectiles at around 200 m/s. At these speeds, microsecond flashes are required to avoid any blurring in the image. I'll re-use the photogate trigger developed for the slower system. Since the muzzle velocity of the air rifles I will be using shows a large variation between shots, I intend to use a dual photogate trigger to measure the projectile velocity as it leaves the rifle. Assembly code on the PIC can use this measurement to compute, while the projectile is in flight, when to fire the first two flashes so the impact can be captured precisely. The timing of the third flash will be a matter of trial and error, since the energetic interaction between the projectile and target is somewhat unpredictable.

A significant portion of this part of the project will be devoted to safety mechanisms to prevent any sort of accidents. Another challenge will be creating bright enough flashes with LEDs. I have had some custom LEDs made which I intend to drive with 1 microsecond current pulses of up to 150 amps. The lifetime of these LEDs under such abuse remains to be seen: I would consider even a few thousand flashes respectable, considering the setup time required to stage each exposure.

The ultimate goal is a three-frame animation of a 22-caliber lead pellet striking an A19 halogen light bulb. I saved the old bulbs when I replaced them with LED versions for just such an occasion.

  • Flash Boards Arrived

    Ted Yapo12/11/2016 at 01:22 0 comments

    The PCBs for the flash boards (and the pulse hubs) arrived last night, as did the DigiKey box with all the parts - that doesn't happen often enough :-) I found some time to assemble and start testing one of the flash boards today. The back view shows the aluminum polymer caps:

    The screw terminals are "backwards" so I can mount these boards in a tight grid (R, G, B) with possibly more than one board per color. The front of the board shows the LEDs, 4-chip "5W" packages, as well as a single lens/reflector I was testing:

    All the components on the back were reflow soldered on the skillet, then the LEDs and connectors were soldered on manually. The board seems to work as designed, with the exception of the footprint for the SMA connector - the corner mounting holes are too small.

    I don't know how I screwed this up - the square root of 2 is still around 1.414, right?? Anyway, rather than drill out the nice plated-though holes, I filed down the connector to make it fit.

    Measurements

    I tested the board at a number of different LED voltages - the flash controller board will have software-adjustable regulators for setting these, since the different color LEDs have different forward voltages, and the red LEDs appear to all be in parallel in the package, instead of the series/parallel arrangement of the green and blue.

    Here's the waveform across the 0.1-ohm resistor in series with one of the LEDs:

    The voltage is measured across a 0.1-ohm resistor with a 2x Z0 probe, so this pulse represents 14.9A of current through one of the 10 LEDs. The supply voltage was 18.5V for this pulse - the capacitors are rated 25V, so I could go somewhat higher. Since the LEDs are rated for 700 mA, this represents about a 21x overdrive. After several hundred pulses, I couldn't detect any changes in the LEDs, but obviously I need to test it a lot more.

    Design

    The nice shape of the waveform and minimal ringing is due in large part to some design hints I got from others here.

    The NCP81074 10A MOSFET gate driver was completely over-sized for a single MOSFET, but does well driving 10 of them. A 100-ohm resistor at each gate keeps the edges relatively slow preventing overshoot and ringing. The 2A Schottky diode across the LED protects it against the brief reverse-bias overshoot on the trailing edge. I included sites for AC-terminating the 50-ohm input, but haven't populated them. I'm going to drive the board from series-terminated sources, so I don't expect a problem, but they're there if needed. Bypass caps aren't shown.

    I included the R1 and R2 resistors right at the output of the driver in case series terminations were required to tame reflections on the gate drive line. The driver has edges of a few nanoseconds, and you can see a light ring/reflection after about a quarter of the rise time of the pulse above. I suspect the inductance of the long, branching gate drive trace on the PCB is to blame. I actually populated R1 and R2 with 0.1 ohm R's, so I can probe them and have a look at what's going on. Resistors of maybe 10 ohms there might help eliminate that one annoying ring. When I get a chance, I'll post a better scope trace of the offending ripple.

    Overall, this board looks like a success. It's bigger with less light output than I originally imagined, but seems pretty manageable and scalable - I can just use as many as I need. Next, I'll figure out which lenses make sense for a useful beam angle, and I can take some test photos.

    I've been working on a photogate design, too. I'll document that soon.

    EDIT - I just did the math. Assuming the forward voltage of the LEDs is around 10V at this current (probably conservative), the pulses dump about 1500W of power into the LEDs.

  • Flash & Pulse Hub Boards

    Ted Yapo11/28/2016 at 15:52 0 comments

    After some reading and thought over the holiday, I designed a PCB to hold 10x of the 4-chip 5W LEDs by Chanzon and others. This could alternately carry 1W or 3W LEDs.

    The front side of the board carries the LEDs and some inexpensive lens/reflectors:

    The lenses are available in a variety of beam angles; I have samples of a few different ones - not sure yet which will end up being most useful. What I do know is that the 120-degree angle of the bare LEDs makes it difficult to get light where you need it. Having lensed LEDs should make this much easier. The lenses press-fit on the LEDs - you can secure them with double-sided tape, but I think being able to change beam angles might come in handy.

    The back of the board has a local flash circuit for each LED:

    I went with aluminum polymer capacitors on this one - @K.C. Lee mentioned them as a possibility a while back, and on this board, I think they'll work out well. Specifically, with just two LED chips in series for each driver, I won't need more than about 20V of supply, maximum. I have some 25V caps selected - I tested a similar circuit with some 20V through-hole polymer caps I had on hand, and it seems to work very well. The low ESR of the cap allows lower voltage operation for the same current pulse, so higher-voltage caps aren't required. These capacitors are large enough (56 uF) that longer, lower-current pulses are also possible with this board - allowing more light for slower scenes. The capacitance doesn't drop with applied voltage like MLCCs :-)

    This board is a step back from my original plan of a few LEDs driven with very high currents. Over the holiday, I had a chance to read Willert, et al. thoroughly. When I initially skimmed this paper, I was impressed that they were able to drive their LEDs with up to 250A. Upon further reading, I saw that the LED they were using, the CBT-120 from Luminus Devices, is rated for 18A continuous current! This large-area (12 mm^2) single-chip LED is designed for LED projectors, and costs over $100 in single quantities (it's actually not recommended for new designs; the replacements are a little more affordable, but not much). So, they're only over-driving the LEDs by a factor of 250/18 ~ 14x. If I want to stick to the same overdrive for 700mA max LEDs, I should pulse them with no more than around 10A. Of course, I will need more LEDs, which is how I got to this board design.

    The other interesting point from the paper is that they claim fast rise-times are LED killers. In one passage, they claim that rise-times of 500ns or less at 250A can destroy their LEDs - although they don't describe the exact mechanism. In another place, they claim they drive LEDs with pulses as short as 100ns, though, so I'm not quite sure what to make of it. In any case, I have sites for MOSFET base resistors on the PCB to control the rise and fall times. While I'm waiting for these boards, I can do some experiments on the previous prototype to see if limiting the current pulse to around 14x overdrive and controlling the transition times extends the LED lifetime.

    In that paper, they were driving 12 mm^2 LED chips (for a different application). On one board, I'll have 10 LEDs with 4 30x30mil chips each, for a total area of 23.2 mm^2. You could also populate the board with 3W LEDs (45x45 mil chips) for 13 mm^2 total - if pulsing the series/parallel 5W LEDs is a problem, I can always fall back to these.

    One issue with the smaller current pulses is that I'll need more LEDs to get the required light output. I think that even 10 LEDs won't be enough, so I'm planning to be able to drive more of these boards as required - this will also make it easier to get light where it's needed, since each board can be independently positioned.

    Pulse Hub

    I thought about adding multiple outputs to the timer/controller board (still to be designed) to allow connection of multiple flash boards, but decided it would take up...

    Read more »

  • First Eposure Test

    Ted Yapo11/23/2016 at 03:12 0 comments

    While I was sanity checking the flash timing, I figured I should make sure the light estimates were roughly in-line, too. I used the second prototype with a "5W" green LED (4 30x30 mil chips). The power supply I had on that bench limited me to 10V, so I could only run the LED with 4.4A pulses. Here's an exposure from a single 1.08 us flash from the LED:

    Sure, it's grainy, and could use a lot more light over a bigger area, but that's with a single $1.23 LED. It's also less than half the brightness I had achieved before with a 24V supply. According to my photodiode sensor, the 24V pulse was 2.23x as bright. I'll have to drag the other supply over there and test it out.

    I'm going to call it a success. There's plenty of room for improvement, but it's encouraging.

  • How fast does it have to be?

    Ted Yapo11/22/2016 at 17:09 0 comments

    I'm still working on the LED pulse circuit, but thought I would take a step back and figure out exactly how fast it needs to be. I did some early calculations to come up with a 1 us flash duration, but thought I should revisit the issue. To get a handle on things, I photographed a rule at the minimum focus distance for the lens I intend to use - about 36 cm away. I could add a macro spacer ring to allow closer focus, but I don't want to endanger the camera by getting it too close to the action. Here's the rule ( what's on the other side of rulers in metric-system countries? )

    The horizontal field of view is about 15cm - knowing this will come in handy later. Zooming in at the center of the image, we can measure the resolution in pixels/mm:

    There are about 20 pixels/mm - we can use this number to figure the required flash duration based on the projectile speed and allowed image blurring.

    My initial tests will be with a CO2-powered air rifle at about 600 fps - that's approximately 180 m/s. I would eventually like to photograph a supersonic projectile at around 350 m/s - spring piston rifles can do this. Based on these two data points, I came up with the following chart, which shows the blur length in pixels for a projectile at either speed photographed with various flash durations:

    Flash Duration
    Velocity (m/s) 100 ns 200 ns 500 ns 1 us 2 us 5 us 10 us
    180 0.36 0.72 1.8 3.6 7.2 18 36
    350 0.7 1.4 3.5 7 14 35 70

    An absolute razor-sharp image might require less than 0.5 pixel blur, but these speeds are probably unrealistic based on the amount of light required for the exposure. Wide open at f/1.8, the lens can't even manage a crystal-clear image at this resolution. To put these numbers in perspective, here's an image of the .22-caliber projectile:

    The pellet is approximately 7 mm long - 140 pixels in the original image. Based on the above table, if we wanted to photograph this pellet with no more than a 10% blur, we would need around a 4 us flash at 180 m/s, or 2 us at 350 m/s. The original target of a 1 us duration would provide around 2.6% blur at 180 m/s. On the other hand, extending the pulse to 10 us would produce 10x as much light, while blurring the pellet by 25% - probably not a great photograph, but interesting nonetheless.

  • Fried Green LEDs

    Ted Yapo11/20/2016 at 23:28 20 comments

    I knew it would happen at some point. I killed some 30x30 mil LED chips in this stock 10W green package. The remaining good ones still light off DC:

    Actually two others in the left string also appear at higher currents; before the "event," they all had similar forward voltages and would all light about equally at a few mA.

    What Happened?

    I built this new flash circuit using a NTD5867NL MOSFET driven by the NCP81074B gate driver IC. The circuit has the same topology as I used before - this time, I substituted a 100 milliohm 1206 for the current sense resistor, and started with the 40uF photoflash capacitor. The idea with this test was to see how high I could get the current at reasonable voltages. The MOSFET is rated for 60V Vdss, so I figured 50 might be a decent de-rating for tests.

    With the 40uF cap in the circuit, I tested the pulses up to 50V. This is the voltage across the 100-milliohm sense resistor as measured with my soldered-on 2x Z0 probe. I believe that ringing is really present in the circuit, since the Z0 probe terminates the coax at both ends, and has shown clean pulses before. Accounting for Rsense and the 2x probe, the cursor measurement is at around 23A. With a 50V supply, this isn't great.

    The optical pulse, as measured with my biased photodiode looks good, shape-wise:

    the cyan trace seems to confirm the ringing issue - the light is ringing, too! The optical pulse would be fine for a camera exposure, though, capturing a clean 1.086 us instant.

    I wasn't satisfied with 23A - that's less than 8A for each LED chip, and I had pumped 12 or so into the smaller ones before. I knew the 40uF capacitor had a high ESR limiting the current, so I replaced it with a 100uF photoflash unit, expecting a smaller ESR but perhaps a larger ESL. With the 100 uF capacitor in place, I turned up the voltage, eventually reaching the 50V mark. Before I could measure the current or take a screenshot on the scope, though, the current waveform began to droop - pulse by pulse (about 1Hz), the waveform fell little by little until it came to rest at less than half of what it had been. At the same time, some of the LEDs stopped working.

    The Cure?

    My suspicion is that the LEDs were killed by overstress transients caused by the ringing. I had recently found the paper Pulsed operation of high-power light emitting diodes for imaging flow velocimetry by Willert, et al. In their driver circuit, using a similar MOSFET/capacitor arrangement, they place a BYT 01-400 rectifier diode reversed across the LED. They state that:

    Diode D1 protects the LED from potentially damaging reverse currents that arise during the rapid switching transients of the circuit.

    sounds like what I've just experienced. I'm not sure about their choice of diode, though - that rectifier diode has a reverse recovery time of 55ns, which sounds too slow. Maybe the LED-killing transients are at the end of the pulse? You can see the red curve above spike negative when the LED is turned off. At the end of the pulse, you don't care about the trr of the protection diode.

    My next step is to replace this LED with a fresh one and add a protection diode - but which one? Jack Smith has done some great measurements on forward and reverse recovery time in various diodes. His studies indicate that even the lumbering 1N4007 with it's 3us trr switches on in a few nanoseconds to eat transients. Luckily, I have more 1N4007s than I will ever use.

    I am a little concerned by the long bond wires in this LED package, though. Maybe it would be better to go with the 5W LEDs that have (4) 30x30 mil chips in a smaller package? I'll have to try some things out.


    Part Two

    I replaced the first LED and added a 1N4007 diode. This one lasted long enough to make some interesting measurements before failing in the same way after about 400 flashes. After failure, some of the LED chips only partly glow. Notice the ones in the lower left:

    While it was still working, I was able...

    Read more »

  • Frame Order

    Ted Yapo11/20/2016 at 13:45 0 comments

    Just a random thought - maybe I should switch the RGB flash order to have the least-ghosting colors first. Since the ghost-correction algorithm is never going to be perfect, you'll always be able to detect at least some subtle ghosting. In looking at the tests I've done so far, ghosts of the future seem much more disturbing than ghosts of the past. Either your used to perceiving after-images from moving objects, or the notion of them doesn't seem odd. Pre-images of what is about to happen is outside our normal experience, and looks really distracting in the GIF loops. If I put the flashes in R (least ghosting), B (medium ghosting), and G (most ghosting), the ghosts are mostly from past frames, which should look less distracting. I think.

  • More Frames?

    Ted Yapo11/18/2016 at 15:05 7 comments

    1 million farmes/second is cool (I still have a way to go before I get there), but 3 total frames is limiting. How can we take more frames?

    More LEDs?

    The first thought is more LEDs, but without more color sensors, there's a problem. To reconstruct the individual frames, we use the inverse of the matrix M:

    but, if M isn't square, there isn't an inverse. With more LEDs than color sensors in the camera, we end up with an indeterminate system and no unique solution. To get more frames with more LEDs we need more than just the red, green, and blue sensors in the camera.

    CYGM Sensors

    Before the modern DSLR era, camera manufacturers flirted with 4-color sensors in some point-and-shoot consumer cameras. About a dozen different models were produced in the late 1990s and early 2000s. The Wikipedia article discusses these cameras and their cyan, yellow, green, and magenta sensitive pixels. If I could find one of these cameras on Ebay, I might be able to coax four frames out of it if I could find appropriate LEDs. It seems like a lot of work for one more frame (now 33% more frames!), but it's a possibility.

    Multiple Cameras

    Synchronizing a mechanical shutter with events on the microsecond scale is not likely to be possible. It would be possible to capture the same three instants from multiple viewpoints using multiple cameras. That could be interesting - multiple cameras at different viewpoints is how the original bullet-time special effects in The Matrix were done, but it doesn't give more frames.

    It might be possible to simulate having more color sensors by using narrow-band color filters on a number of cameras. Since the response of the red, green, and blue pixels on the camera sensor are pretty wide, several narrow-band filters could be used (with different cameras) to capture light from several different colored LEDs. Maybe at most, you might do {royal blue, blue, cyan, green, yellow, red, deep red} for seven frames, maybe requiring seven cameras. Again, this sounds like a lot of work (and expense) for a mediocre gain.

  • Moving Dice Test

    Ted Yapo11/18/2016 at 04:10 6 comments

      It turns out that you can make some 3-frame animations of rolling dice with just the 3W red, green, and blue LEDs driven with normal BJTs and 1k resistors from an Arduino. I used two pieces of aluminum foil as a trigger - the falling die presses one against the other, closing the circuit. It's a pain-in-the-ass to adjust, but I got it to work OK for some tests.

      The flash sequence starts when the die hits the table, so this sequence is of the subsequent bounce. I experimented with 1 ms flashes, then moved to 200 us. From these experiments, I think if I can get 100x more light than I'm getting from these single-chip LEDs (driven below their rated current), I should be able to take some initial bullet photographs. More would be better :-)

      What's Wrong?

      There are a few issues I have been able to identify so-far:

      1. Some pixels (especially in the blue channel) are saturated 255. The ghosting-correction algorithm fails for these pixels. I think the only solution is to ensure no pixels in the image are saturated in any channel. The saturated areas in the above image are easy to spot.
      2. The brightnesses of the three channels don't match. I applied some hard-coded corrections to these animations, but I think I need to write an automatic brightness adjuster to eliminate this annoying effect
      3. The ghost-correction calibration has to be done at the same LED current used for the actual flash. I just used my original test calibration for this sequence, and it doesn't work that well. The problem is that the LED colors shift somewhat (blue shift) at different currents. To get the best images, a calibration will need to be done with the same duration and current flashes used for the photograph.

      There are obviously issues to fix, but it seems like this is going to work. If I can get 1 us flashes bright enough, that's the equivalent of 1 million non-overlapping frames per second (for a 3-frame burst).

      Gallery

      Here are some other test images, shown along with the original RGB frame from the camera:

  • What can I do with just the 3W LEDs?

    Ted Yapo11/18/2016 at 02:22 0 comments

    So, I started thinking ... I used 1 second exposures (G, B, anyway) for the original still dice images. To get the correct exposure, I had to set the camera to ISO 100 and the lens to f/22. The ISO will go up to 3200, and the lens opens to f/1.8 (I cannot justify buying the very nice Canon f/1.4 or the coveted f/1.2). At these settings, the camera is:

    times as sensitive. I should be able to use 210 us flashes and get the same exposure! That should be fast enough to capture the dice in motion, even using lousy 1-chip 3W LEDs driven with a BJT and a resistor.

    I have to get down to the bench now.

    I think I can make a simple trigger with two pieces of aluminum foil that get pressed together by falling dice.

  • References

    Ted Yapo11/17/2016 at 20:30 0 comments

    As usual, I started this project by diving in and building something. Now, it might be time to do some research on the topic ;-) I found some interesting references, so I'll list them here (and update as I find more). I've just started, so this list is probably totally incomplete.

    When I still had access to an academic library, I found a paper from the 1960s (I believe) that discussed red, green, and blue flashes from filtered gas discharge lamps to capture three instants in time on a single color film emulsion. This was in maybe 2009. I haven't been able to find it again since (and no longer have access to the library).


    LED Manufacturers

    Cree weighs in with this whitepaper:

    http://www.cree.com/~/media/Files/Cree/LED Components and Modules/XLamp/XLamp Application Notes/XLampPulsedCurrent.pdf

    How much current can you use? Their opinion "it depends." They also state "For duty cycles less than 10%, do not exceed more than 300% of the maximum rated current". Unfortunately, this just isn't going to produce enough light. Although LED efficiency drops dramatically at higher currents (due to an effect known as "droop"), you still typically get more light with more current.


    Commercial LED Strobes

    There was a Kickstarter for the "Vela One," and LED strobe that boasts 500ns pulses with white LEDs:

    https://www.kickstarter.com/projects/vela/vela-one-the-worlds-first-high-speed-led-flash

    They claim they drive 9 LEDs (they don't say how many chips per "LED", although I'd guess they are 50 or 100W LEDs) at 20x their normal brightness. If this is true, it means more than 20x their normal current. Comments in the Hackaday article listed below would indicate they observed a 50% reduction in efficiency, meaning 40x the normal current.


    This device:

    http://smartvisionlights.com/downloads/datasheets/XR256_Datasheet.pdf

    claims 288 mm^2 of LED chip area at 180A, but is designed as a rapid strobe light instead of emitting a single-flash. This works out to 625 mA/mm^2. I have already run 30A into two paralleled 30x30mil chips. If my math is correct, that's about 26A/mm^2. A huge difference. Of course, they do this up to 5,000 time per second for long periods. I would count myself very lucky to get 5,000 total flashes from my device before it fails.


    Gardasoft, who make industrial LED illuminators, have a nice whitepaper about overdriving LEDs:

    http://www.gardasoft.com/Downloads/

    See their "APP930 - Overdriving LEDs" document; I can't link directly to it here. They claim that overdriving current by 100x is OK for 1us pulses. The 45x45 mil "3W" chips I intend to use are rated for 500 mA (documentation varies). 100x overdrive would be 50A/chip.


    Hackaday Articles

    This one was written up on Hackaday.

    https://hackaday.com/2015/10/05/frozen-time-photography-with-a-100w-led/

    This one used a 60V supply and a 100W white LED. An interesting project, but as expected, the really useful information is in the comments. I just found this one, so I haven't digested them all, but a brief glance didn't reveal any showstopper issues. I knew brightness was a problem.


    Academic Papers

    Here's an article with a similar LED pulser (again monochromatic: white or green):

    http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.474.6388&rep=rep1&type=pdf

    I haven't read this one thoroughly, yet either. Most interesting line in skimming the paper: "For pulse widths below 5μs the maximum pulse current is limited to If ≈ 250 A". That's a lot of current, and it makes me happy.


    This one uses three filtered xenon flashes for schlieren photography. I have only read the abstract:

    http://spie.org/Publications/Proceedings/Paper/10.1117/12.209576


    Here's a paper from 1995 using a CCD camcorder and filtered xenon flashes to increase the video frame rate. They claim more than 10,000 fps. They also mention "correction equations" to correct...

    Read more »

View all 18 project logs

Enjoy this project?

Share      

Discussions

sakupiec wrote 11/20/2016 at 03:35 point

Very Neat. Having done quite a bit of high speed work with LEDs and cameras you might want to look at some options. 

You may want to look at the LT3743 driver chip. there is an excellent DC1470A evaluation module that should hit 1 us out of the box. At these speeds you can appreciably higher currents than the DC rated values. I run a 4A 38kHz 10% duty cycle without breaking a sweat. These can drive some pretty insane LEDs like the Phatlight series. Just make sure to power up the DC1470A AFTER your logic boards come up. 

You may also want to consider Fluttershutter modulation which can considerably reduce blurring while increasing exposure:

http://web.media.mit.edu/~raskar/deblur/

https://www.researchgate.net/publication/276513450_Motion_deblurring_with_temporally_coded_illumination_in_an_LED_array_microscope

  Are you sure? yes | no

Ted Yapo wrote 11/20/2016 at 05:39 point

Thanks for the tips!

I had seen the LT3743 discussed in the new Art of Electronics - Messrs. Horowitz and Hill are impressed with it, too.  I'll have a closer look, but back-of-the-envelope calculations put me in the 100A range (which I supposedly can get away with in the microsecond regime).  Capacitors and MOSFETs are looking good at this point, but who knows.

The flutter shutter paper is interesting - I think I skimmed it a while back.  It seems like a good technique for moving objects which don't change appearance much over the total exposure time - i.e. good for reducing classic motion blur.  For objects with rapidly changing appearance, maybe not so much.  I hope to capture some objects whose appearance changes rapidly :-)  There might be something in there, though.  I'll definitely give it a thorough read...

  Are you sure? yes | no

David H Haffner Sr wrote 11/17/2016 at 08:35 point

Congrat's on begin featured on the front page!

  Are you sure? yes | no

Ted Yapo wrote 11/17/2016 at 15:07 point

Thank you! 

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/11/2016 at 06:45 point

Oh, that explains the custom RGB LED assembly story...

  Are you sure? yes | no

Ted Yapo wrote 11/11/2016 at 13:34 point

Yep.  I didn't mean to make it sound mysterious before, but there's a lot of context.

We'll see how the LEDs work out.  My first idea was to use Luxeon Z LEDs, which you could pack onto an arbitrarily large PCB at an amazing density (and at amazing cost).  Unfortunately, these LEDs appear to have zener ESD protection chips wired into the package.  My concern is that the zeners would conduct during the brief high-current (and necessarily high voltage pulses) I'd need.

I think you mentioned similar issues with previous generation Luxeons and their built-in protection devices.  "Real Engineers" add such protection themselves, if it's required...I don't need LED manufacturers making these decisions for me.  Not that I'm a real engineer :-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/11/2016 at 14:29 point

amen......

  Are you sure? yes | no

Does this project spark your interest?

Become a member to follow this project and never miss any updates